<div dir="ltr">Hello, <div><br></div><div>Have you already considered what Jan Vondra sent to this discussion ? </div><div>I am just making sure that this was read.</div><div><br></div><div>Thanks,<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="margin:0px;padding:0px 0px 20px;width:1503px;color:rgb(34,34,34);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium"><div style="margin:8px 0px 0px;padding:0px"><div dir="ltr"><span><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" style="font-family:Arial,Helvetica,sans-serif;font-size:small"><span style="color:rgb(136,136,136);vertical-align:top;line-height:18px;font-size:11pt;font-family:Arial,Helvetica,Geneva;font-weight:bold">Michal Arbet<br></span><span style="color:rgb(136,136,136);font-size:10pt;vertical-align:top;line-height:18px;font-family:Arial,Helvetica,Geneva">Openstack Engineer<br><img src="https://www.google.com/a/ultimum.io/images/logo.gif" width="200" height="81"><br>Ultimum Technologies a.s.<br>Na Poříčí 1047/26, 11000 Praha 1<br>Czech Republic<br><br><a value="+420608314961" style="color:rgb(17,85,204)">+420 604 228 897</a> <br><a href="mailto:michal.arbet@ultimum.io" style="color:rgb(17,85,204)" target="_blank">michal.arbet@ultimum.io</a><br></span><font color="#1155cc" face="Arial, Helvetica, Geneva" style="font-size:12.8px"><span style="font-size:13.3333px;line-height:18px"><u><a href="https://ultimum.io/" style="color:rgb(17,85,204)" target="_blank">https://ultimum.io</a></u></span></font><br></div><div dir="ltr" style="font-family:Arial,Helvetica,sans-serif;font-size:small"><font color="#1155cc" face="Arial, Helvetica, Geneva" style="font-size:12.8px"><span style="font-size:13.3333px;line-height:18px"><br></span></font></div><div style="font-family:Arial,Helvetica,sans-serif;font-size:small"><font color="#666666"><a href="https://www.linkedin.com/company/ultimum-technologies" style="color:rgb(17,85,204)" target="_blank">LinkedIn</a> | <a href="https://twitter.com/ultimumtech" style="color:rgb(17,85,204)" target="_blank">Twitter</a> | <a href="https://www.facebook.com/ultimumtechnologies/timeline" style="color:rgb(17,85,204)" target="_blank">Facebook</a></font></div></div></div></div></div></div></div></div></span></div></div><div><div></div><div><div></div></div></div><div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">st 24. 11. 2021 v 14:30 odesílatel Jan Vondra <<a href="mailto:jan.vondra@ultimum.io">jan.vondra@ultimum.io</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi guys,<br>I've been further investigating Michal's (OP) issue, since he is on his holiday, and I've found out that the issue is not really plugging the VIF but cleanup after previous port bindings.<br><br>We are creating 6 servers with 2-4 vifs using heat template [0]. We were hitting some problems with placement so the stack sometimes failed to create and we had to delete the stack and recreate it.<br>If we recreate it right after the deletion, the vif plugging timeout occurs. If we wait some time (approx. 10 minutes) the stack is created successfully.<div><br></div><div>This brings me to believe that there is some issue with deferring the removal of security groups from unbound ports (somewhere around this part of code [1]) and it somehow affects the creation of new ports. However, I am unable to find any lock that could cause this behaviour.<br><br>The only proof I have is that after the stack recreation scenario I have measured that the process_network_ports [2] function call could take up to 650 s (varies from 5 s to 651 s in our environment).</div><div><br>Any idea what could be causing this? <br clear="all"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p>[0] <a href="https://pastebin.com/infvj4ai" target="_blank">https://pastebin.com/infvj4ai</a><br>[1] <a href="https://github.com/openstack/neutron/blob/master/neutron/agent/firewall.py#L133" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/agent/firewall.py#L133</a><br>[2] <a href="https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L2079" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L2079</a></p>






<div>
<p><b><span style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(136,136,136)">Jan Vondra</span></b><span style="font-size:10pt;font-family:Arial,sans-serif;color:rgb(136,136,136)"><br>
</span><u><span style="font-size:10pt;font-family:Arial,sans-serif;color:rgb(17,85,204)"><a href="http://ultimum.io" target="_blank">http://ultimum.io</a></span></u></p></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">st 24. 11. 2021 v 11:08 odesílatel Bogdan Dobrelya <<a href="mailto:bdobreli@redhat.com" target="_blank">bdobreli@redhat.com</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/24/21 1:21 AM, Tony Liu wrote:<br>
> I hit the same problem, from time to time, not consistently. I am using OVN.<br>
> Typically, it takes no more than a few seconds for neutron to confirm the port is up.<br>
> The default timeout in my setup is 600s. Even the ports shows up in both OVN SB<br>
> and NB, nova-compute still didn't get confirmation from neutron. Either neutron<br>
> didn't pick it up or the message was lost and didn't get to nova-compute.<br>
> Hoping someone could share more thoughts.<br>
<br>
That also may be a super-set of the revert-resize with OVS hybrid plug<br>
issue described in [0]. Even though the problems described in the topic<br>
may have nothing to that particular case, but does look related to the<br>
external events framework.<br>
<br>
Issues like that make me thinking about some improvements to it.<br>
<br>
[tl;dr] bring back up the idea of buffering events with a ttl<br>
<br>
Like a new deferred RPC calls feature maybe? That would execute a call<br>
after some trigger, like send unplug and forget. That would make<br>
debugging harder, but cover the cases when an external service "forgot"<br>
(an event was lost and the like cases) to notify Nova when it is done.<br>
<br>
Adding a queue to store events that Nova did not have a recieve handler<br>
set for might help as well. And have a TTL set on it, or a more advanced<br>
reaping logic, for example based on tombstone events invalidating the<br>
queue contents by causal conditions. That would eliminate flaky<br>
expectations set around starting to wait for receiving events vs sending<br>
unexpected or belated events. Why flaky? Because in an async distributed<br>
system there is no "before" nor "after", so an external to Nova service<br>
will unlikely conform to any time-frame based contract for<br>
send-notify/wait-receive/real-completion-fact. And the fact that Nova<br>
can't tell what the network backend is (because [1] was not fully<br>
implemented) does not make things simpler.<br>
<br>
As Sean noted in a private irc conversation, with OVN the current<br>
implementation is not capable of fullfilling the contract that<br>
network-vif-plugged events are only sent after the interface is fully<br>
configred. So it send events at bind time once it have updated the<br>
logical port in the ovn db but before real configuration has happened. I<br>
believe that deferred RPC calls and/or queued events might improve such<br>
a "cheating" by making the real post-completion processing a thing for<br>
any backend?<br>
<br>
[0] <a href="https://bugs.launchpad.net/nova/+bug/1952003" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1952003</a><br>
<br>
[1]<br>
<a href="https://specs.openstack.org/openstack/neutron-specs/specs/train/port-binding-extended-information.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/neutron-specs/specs/train/port-binding-extended-information.html</a><br>
<br>
> <br>
> Thanks!<br>
> Tony<br>
> ________________________________________<br>
> From: Laurent Dumont <<a href="mailto:laurentfdumont@gmail.com" target="_blank">laurentfdumont@gmail.com</a>><br>
> Sent: November 22, 2021 02:05 PM<br>
> To: Michal Arbet<br>
> Cc: openstack-discuss<br>
> Subject: Re: [neutron][nova] [kolla] vif plugged timeout<br>
> <br>
> How high did you have to raise it? If it does appear after X amount of time, then the VIF plug is not lost?<br>
> <br>
> On Sat, Nov 20, 2021 at 7:23 AM Michal Arbet <<a href="mailto:michal.arbet@ultimum.io" target="_blank">michal.arbet@ultimum.io</a><mailto:<a href="mailto:michal.arbet@ultimum.io" target="_blank">michal.arbet@ultimum.io</a>>> wrote:<br>
> + if i raise vif_plugged_timeout ( hope i rember it correct ) in nova to some high number ..problem dissapear ... But it's only workaround<br>
> <br>
> Dňa so 20. 11. 2021, 12:05 Michal Arbet <<a href="mailto:michal.arbet@ultimum.io" target="_blank">michal.arbet@ultimum.io</a><mailto:<a href="mailto:michal.arbet@ultimum.io" target="_blank">michal.arbet@ultimum.io</a>>> napísal(a):<br>
> Hi,<br>
> <br>
> Has anyone seen issue which I am currently facing ?<br>
> <br>
> When launching heat stack ( but it's same if I launch several of instances ) vif plugged in timeouts an I don't know why, sometimes it is OK ..sometimes is failing.<br>
> <br>
> Sometimes neutron reports vif plugged in < 10 sec ( test env ) sometimes it's 100 and more seconds, it seems there is some race condition but I can't find out where the problem is. But on the end every instance is spawned ok (retry mechanism worked).<br>
> <br>
> Another finding is that it has to do something with security group, if noop driver is used ..everything is working good.<br>
> <br>
> Firewall security setup is openvswitch .<br>
> <br>
> Test env is wallaby.<br>
> <br>
> I will attach some logs when I will be near PC ..<br>
> <br>
> Thank you,<br>
> Michal Arbet (Kevko)<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
<br>
<br>
-- <br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br>
<br>
</blockquote></div>
</blockquote></div>