<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 13, 2020 at 1:18 PM Slawek Kaplonski <<a href="mailto:skaplons@redhat.com">skaplons@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">Hi,<br>
<br>
On Wed, May 13, 2020 at 09:42:28AM +0200, Luis Tomas Bolivar wrote:<br>
> Hi Nate,<br>
> <br>
> I think I'm getting configure with the use of "instances" here. With<br>
> instances, you refer to VMs? Note there is a need to first create the<br>
> parent, then the trunk and then the instance using that parent.<br>
> <br>
> Also, deleting the VM is not a problem, it will just move the port to down<br>
> (and the trunk). The problem is deleting the parent port (if it is part of<br>
> the trunk). I think the problem here is that the VM should not try to<br>
> delete the port as port was existing before VM creation, right?<br>
<br>
It is like that if You create port in neutron, and then pass this port to the<br>
Nova when booting instance.<br>
But if You first create instance by giving network_id to Nova, it will create<br>
port on this network for You and that port will be deleted by Nova when instance<br>
will be deleted.<br></blockquote><div><br></div><div>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</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> Note too that if the parent port is not "eligible" after being part of a<br>
> trunk, how can you boot a VM with a parent port given that there is a need<br>
> for having the trunk before booting the VM?<br>
> <br>
> Cheers,<br>
> Luis<br>
> <br>
> On Tue, May 12, 2020 at 4:13 PM Nate Johnston <<a href="mailto:nate.johnston@redhat.com" target="_blank">nate.johnston@redhat.com</a>><br>
> wrote:<br>
> <br>
> > Neutron developers,<br>
> ><br>
> > I am currently working on an issue with trunk ports that has come up a few<br>
> > times<br>
> > in my direct experience, and I hope that we can create a long term<br>
> > solution. I<br>
> > am hoping that developers with experience in trunk ports can validate my<br>
> > approach here, especially regarding fixing current behavior without<br>
> > introducing<br>
> > an API regression.<br>
> ><br>
> > By way of introduction to the specifics of the issue, let me blockquote<br>
> > 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<br>
> > trunk and<br>
> > attach the trunk to the parent. Then subports can be created on the<br>
> > trunk. When<br>
> > instances are created on the trunk, first a port is created and then<br>
> > an instance<br>
> > is associated with a free port. It looks to me that's this is the<br>
> > oversight in<br>
> > the logic.<br>
> ><br>
> > From the perspective of the code, the parent port looks like any other<br>
> > port<br>
> > attached to the trunk bridge. It doesn't have an instance attached to<br>
> > it so it<br>
> > looks like it's not being used for anything (which is technically<br>
> > correct). So<br>
> > it becomes an eligible port for an instance to bind to. That is all<br>
> > fine and<br>
> > dandy until you go to delete the instance and you get the "Port<br>
> > [port-id] is<br>
> > currently a parent port for trunk [trunk-id]" exception just as<br>
> > happened here.<br>
> > Anecdotally, it's seems rare that an instance will actually bind to<br>
> > it, but that<br>
> > is what happened for the user in this case and I have had several<br>
> > 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<br>
> > trunk be<br>
> > established as the owner of the port. That way it will be ineligible<br>
> > for<br>
> > instances seeking to bind to the port.<br>
> ><br>
> > ----<br>
> ><br>
> > Clearly the above behavior indicates buggy issue that should be rectified<br>
> > 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<br>
> > it<br>
> > causes heat stack deletion failures.<br>
> ><br>
> > I am mostly concerned that by adding the trunk as an owner of the parent<br>
> > port,<br>
> > then the trunk will need to be deleted before the parent port can be<br>
> > deleted,<br>
> > otherwise a PortInUse error will occur when the port is deleted (i.e. on<br>
> > tempest<br>
> > test teardown). That to me seems indicative of an inadvertent API<br>
> > change. Do<br>
> > you think it's all right to say that if you delete a port that is a parent<br>
> > port<br>
> > of a trunk, and that trunk has no other subports, that the trunk deletion<br>
> > is<br>
> > implicit? Is that the lowest impact to the API that we can incur to<br>
> > 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>
> ><br>
> <br>
> -- <br>
> 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>
-- <br>
Slawek Kaplonski<br>
Senior software engineer<br>
Red Hat<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>