>I kind of think it makes sense to require evacuating a segment of its ports before deleting it.
Ah, I left out an important assumption I was making. We also need to auto delete the DHCP port as the segment is deleted. I was thinking this will be basically be like the delete_network case where we will auto remove the network owned ports. On Tue, May 17, 2016 at 12:29 PM, Carl Baldwin <[email protected]> wrote: > On Tue, May 17, 2016 at 10:56 AM, Kevin Benton <[email protected]> wrote: > >>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. > > I agree with Kevin here. > > >>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. > > Sounds reasonable. > > > 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. > > They will be left somewhat defunct, won't they? I think a foreign key > constraint would be violated if you tried to delete a segment with > even a DHCP port on it. > > port <- ipallocations (FK) -> subnets (FK) -> networksegments > > I guess there is no foreign key constraint holding the ipallocations > to the port. So, the ipallocations could be deleted. But, that is > effectively stripping an existing port of its IP addresses which would > be weird. > > I kind of think it makes sense to require evacuating a segment of its > ports before deleting it. > > >>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. > > ++ Simplify! We don't have a use case for this now. > > Carl > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
