On Wed, May 13, 2020 at 1:18 PM Slawek Kaplonski <skaplons@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
On Thu, 2020-05-14 at 08:45 +0200, Luis Tomas Bolivar wrote: 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@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
-- LUIS TOM�S BOL�VAR Senior Software Engineer Red Hat Madrid, Spain ltomasbo@redhat.com
-- Slawek Kaplonski Senior software engineer Red Hat