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