[neutron] parent ports for trunks being claimed by instances

Luis Tomas Bolivar ltomasbo at redhat.com
Thu May 14 06:45:56 UTC 2020


On Wed, May 13, 2020 at 1:18 PM Slawek Kaplonski <skaplons at redhat.com>
wrote:

> Hi,
>
> On Wed, May 13, 2020 at 09:42:28AM +0200, Luis Tomas Bolivar wrote:
> > Hi Nate,
> >
> > I think I'm getting configure with the use of "instances" here. With
> > instances, you refer to VMs? Note there is a need to first create the
> > parent, then the trunk and then the instance using that parent.
> >
> > Also, deleting the VM is not a problem, it will just move the port to
> down
> > (and the trunk). The problem is deleting the parent port (if it is part
> of
> > the trunk). I think the problem here is that the VM should not try to
> > delete the port as port was existing before VM creation, right?
>
> It is like that if You create port in neutron, and then pass this port to
> the
> Nova when booting instance.
> But if You first create instance by giving network_id to Nova, it will
> create
> port on this network for You and that port will be deleted by Nova when
> instance
> will be deleted.
>

You mean that it is possible to later make that VM port (created by nova) a
parent port of a trunk? That is not supported in ml2/ovs (or it was not
before), I never tried with OVN


>
> >
> > Note too that if the parent port is not "eligible" after being part of a
> > trunk, how can you boot a VM with a parent port given that there is a
> need
> > for having the trunk before booting the VM?
> >
> > Cheers,
> > Luis
> >
> > On Tue, May 12, 2020 at 4:13 PM Nate Johnston <nate.johnston at redhat.com>
> > wrote:
> >
> > > Neutron developers,
> > >
> > > I am currently working on an issue with trunk ports that has come up a
> few
> > > times
> > > in my direct experience, and I hope that we can create a long term
> > > solution.  I
> > > am hoping that developers with experience in trunk ports can validate
> my
> > > approach here, especially regarding fixing current behavior without
> > > introducing
> > > an API regression.
> > >
> > > By way of introduction to the specifics of the issue, let me blockquote
> > > from the
> > > LP bug I raised for this [1]:
> > >
> > > ----
> > >
> > >     When you create a trunk in Neutron you create a parent port for the
> > > trunk and
> > >     attach the trunk to the parent. Then subports can be created on the
> > > trunk. When
> > >     instances are created on the trunk, first a port is created and
> then
> > > an instance
> > >     is associated with a free port. It looks to me that's this is the
> > > oversight in
> > >     the logic.
> > >
> > >     From the perspective of the code, the parent port looks like any
> other
> > > port
> > >     attached to the trunk bridge. It doesn't have an instance attached
> to
> > > it so it
> > >     looks like it's not being used for anything (which is technically
> > > correct). So
> > >     it becomes an eligible port for an instance to bind to. That is all
> > > fine and
> > >     dandy until you go to delete the instance and you get the "Port
> > > [port-id] is
> > >     currently a parent port for trunk [trunk-id]" exception just as
> > > happened here.
> > >     Anecdotally, it's seems rare that an instance will actually bind to
> > > it, but that
> > >     is what happened for the user in this case and I have had several
> > > pings over the
> > >     past year about people in a similar state.
> > >
> > >     I propose that when a port is made parent port for a trunk, that
> the
> > > trunk be
> > >     established as the owner of the port. That way it will be
> ineligible
> > > for
> > >     instances seeking to bind to the port.
> > >
> > > ----
> > >
> > > Clearly the above behavior indicates buggy issue that should be
> rectified
> > > in
> > > master and stable branches.  Nobody wants a VM that can't be fully
> deleted
> > > because the port can't ever be deleted.  This is especially egregious
> when
> > > it
> > > causes heat stack deletion failures.
> > >
> > > I am mostly concerned that by adding the trunk as an owner of the
> parent
> > > port,
> > > then the trunk will need to be deleted before the parent port can be
> > > deleted,
> > > otherwise a PortInUse error will occur when the port is deleted (i.e.
> on
> > > tempest
> > > test teardown).  That to me seems indicative of an inadvertent API
> > > change.  Do
> > > you think it's all right to say that if you delete a port that is a
> parent
> > > port
> > > of a trunk, and that trunk has no other subports, that the trunk
> deletion
> > > is
> > > implicit?  Is that the lowest impact to the API that we can incur to
> > > resolve
> > > this issue?
> > >
> > > Your wisdom is appreciated,
> > >
> > > Nate
> > >
> > > [1] https://bugs.launchpad.net/neutron/+bug/1878031
> > >
> > >
> > >
> >
> > --
> > LUIS TOM�S BOL�VAR
> > Senior Software Engineer
> > Red Hat
> > Madrid, Spain
> > ltomasbo at redhat.com
>
> --
> Slawek Kaplonski
> Senior software engineer
> Red Hat
>
>

-- 
LUIS TOMÁS BOLÍVAR
Senior Software Engineer
Red Hat
Madrid, Spain
ltomasbo at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200514/a4f1e080/attachment-0001.html>


More information about the openstack-discuss mailing list