[neutron] parent ports for trunks being claimed by instances

Sean Mooney smooney at redhat.com
Thu May 14 08:41:33 UTC 2020


On Thu, 2020-05-14 at 08:45 +0200, Luis Tomas Bolivar wrote:
> 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
the behavior should not depend on the backend used.

i.e. form an interoperabltiy point of view there should be no obsverable
difference in how the trunk ports api works if you are using ml2/ovs or ml2/ovn.

my recollection was we do not allow a standar port to be used as a parent for a trunk port
if its attached to a vm currently. so i think you would have to first detach the port form the vm
then make it a trunk port partent and then reattach it to the vm.

i think that workflow is "supported" but only in the sense that it is valid to detach a port and make it
a trunk port. if that ortininal port was created by nova in the boot request you should still expect it to get deleted
and no clean up of the sub ports to be done. hence my "suported" in scare quotes comment above since realistically its a
user error to convert a nova created port into a trunk port parent. at least form a nova point of view we dont support
that.

it might technically work but its not inteneded to an any odd behavior as a result is not a bug.


> 
> 
> > 
> > > 
> > > 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
> > 
> > 
> 
> 




More information about the openstack-discuss mailing list