Open Stack

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