[openstack-dev] [Neutron][ML2][Routed Networks]

Kevin Benton kevin at benton.pub
Tue May 17 20:16:06 UTC 2016

>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 <carl at ecbaldwin.net> wrote:

> On Tue, May 17, 2016 at 10:56 AM, Kevin Benton <kevin at benton.pub> 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: 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/12fb5ef0/attachment.html>

More information about the OpenStack-dev mailing list