>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 <xiaoh...@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 <c...@ecbaldwin.net> > To: OpenStack Development Mailing List > <openstack-dev@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
