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