Open Stack

>a) Deleting network's last segment will be prevented. Every network should have
at least one segment to let the port to bind.

This seems a bit arbitrary to me. If a segment is limited to a small part
of the datacenter, it being able to bind for one section of the datacenter
and not the rest is not much different than being able to bind from no
sections. Just allow it to be deleted because we need to have logic to deal
with the unbindable port case anyway. Especially since it's a racy check
that is hard to get correct for little gain.

>b) Deleting the segment that has been associated with subnet will be
prevented.

+1

>c) Deleting the segment that has been bound to port will be prevented.

+1.

>d) Based on c), we need to query ml2_port_binding_levels, I think
neutron.plugins.ml2.models.PortBindingLevel should be moved out of ml2. This
is also because port and segment are both neutron server resources, no need
to keep PortBindingLevel at ml2.

There are things in this model that make sense only to ML2 (level and
driver), especially since ML2 allows a single port_id to appear multiple
times in the table (primary key is port_id + level).  To achieve your goals
in 'C' above, just emit a BEFORE_DELETE event in the callback registry for
segments. Then ML2 can query this table with a registered callback and
other plugins can register a callback to prevent this however they want.

However, be sure to ignore the DHCP port when preventing segment deletion
otherwise having DHCP enabled will make it difficult to get rid of a
segment.

>e) Is it possible to update a segment(physical_network, segmentation_id, or
even network_type), when the segment is being used?

I would defer this for future work and not allow it for now. If the segment
details change, we need to ask the drivers responsible for every bound port
to make they can support it under the new conditions. It will be quite a
bit of logic to deal with that I don't think we need to support up front.

On Tue, May 17, 2016 at 8:39 AM, Hong Hui Xiao <xiaohhui at cn.ibm.com> wrote:

> Hi,
>
> I create this patch [1] to allow multi-segmented routed provider networks
> to grow and shrink over time, reviews are welcomed. I found these points
> during working on the patch, and I think it is good to bring them out for
> discussion.
>
> a) Deleting network's last segment will be prevented. Every network should
> have at least one segment to let the port to bind.
>
> b) Deleting the segment that has been associated with subnet will be
> prevented.
>
> c) Deleting the segment that has been bound to port will be prevented.
>
> d) Based on c), we need to query ml2_port_binding_levels, I think
> neutron.plugins.ml2.models.PortBindingLevel should be moved out of ml2.
> This is also because port and segment are both neutron server resources,
> no need to keep PortBindingLevel at ml2.
>
> e) Is it possible to update a segment(physical_network, segmentation_id,
> or even network_type), when the segment is being used?
>
> [1] https://review.openstack.org/#/c/317358
>
> HongHui Xiao(肖宏辉)
>
>
>
> From:   Carl Baldwin <carl at ecbaldwin.net>
> To:     OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Date:   05/12/2016 23:36
> Subject:        [openstack-dev] [Neutron][ML2][Routed Networks]
>
>
>
> Hi,
>
> Segments are now a first class thing in Neutron with the merge of this
> patch [1].  It exposes API for segments directly.  With ML2, it is
> currently only possible to view segments that have been created
> through the provider net or multi-provider net extensions.  This can
> only be done at network creation time.
>
> In order to allow multi-segmented routed provider networks to grow and
> shrink over time, it is necessary to allow creation and deletion of
> segments through the new segment endpoint.  Hong Hui Xiao has offered
> to help with this.
>
> We need to provide the integration between the service plugin that
> provides the segments endpoint with ML2 to allow the creates and
> deletes to work properly.  We'd like to here from ML2 experts out
> there on how this integration can proceed.  Is there any caution that
> we need to take?  What are the non-obvious aspects of this that we're
> not thinking about?
>
> Carl Baldwin
>
> [1] https://review.openstack.org/#/c/296603/
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160517/1bbc77fb/attachment.html>