<div dir="ltr">Hi,<div><br></div><div>You can find logs from controller0 and compute0 in attachment (other controllers and computes were turned off for this test).</div><div><br></div><div>Thank you,<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">čt 25. 11. 2021 v 8:22 odesílatel Slawek Kaplonski <<a href="mailto:skaplons@redhat.com">skaplons@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">Hi,<br>
<br>
Basically in ML2/OVS case it may be one of 2 reasons why port isn't <br>
provisioned properly quickly:<br>
- neutron-ovs-agent is somehow slow with provisioning it or<br>
- neutron-dhcp-agent is slow provisioning that port.<br>
<br>
To check which of those happens really, You can enable debug logs in You <br>
neutron-server and look there for logs like "Port xxx provisioning completed <br>
by entity L2/DHCP" (or something similar, I don't remember it now exactly).<br>
<br>
If it works much faster with noop firewall driver, then it seems that it is <br>
more likely to be on the neutron-ovs-agent's side.<br>
In such case couple of things to check:<br>
- are You using l2population (it's required with DVR for example),<br>
- are You using SG with rules which references "remote_group_id" (like default <br>
SG for each tenant does)? If so, can You try to remove from You SG such rules <br>
and use rules with CIDRs instead? We know that using SG with remote_group_id <br>
don't scale well and if You have many ports using same SG, it may slow down <br>
neutron-ovs-agent a lot.<br>
- do You maybe have any other errors in the neutron-ovs-agent logs? Like rpc <br>
message communication errors or something else? Such errors will trigger doing <br>
fullsync of all ports on the node so it may take long time to get to actually <br>
provisioning Your new port sometimes.<br>
- what exactly version of Neutron are You using there?<br>
<br>
On sobota, 20 listopada 2021 11:05:16 CET Michal Arbet wrote:<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<br>
> ) vif plugged in timeouts an I don't know why, sometimes it is OK<br>
> ..sometimes is failing.<br>
> <br>
> Sometimes neutron reports vif plugged in < 10 sec ( test env ) sometimes<br>
> it's 100 and more seconds, it seems there is some race condition but I<br>
> can't find out where the problem is. But on the end every instance is<br>
> spawned ok (retry mechanism worked).<br>
> <br>
> Another finding is that it has to do something with security group, if noop<br>
> 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>
Slawek Kaplonski<br>
Principal Software Engineer<br>
Red Hat</blockquote></div>