<div dir="ltr">The L2 agent, for instance, has a logic to perform "full" synchronisations with the server.<div>These happens in two cases:</div><div>1) upon agent restart, as some messages from the server side might have gone lost</div><div>2) whenever a failure is detected on the agent side (this is probably a bit too conservative).</div><div><br></div><div>Salvatore<div><div class="gmail_extra"><br><div class="gmail_quote">On 14 March 2015 at 10:51, Leo Y <span dir="ltr"><<a href="mailto:minherz@gmail.com" target="_blank">minherz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello <span style="font-size:12.8000001907349px">Rossella,</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I meant to something different, to less conventional changes. Right now, the network topology state is stored in neutron DB and each compute node "knows" about it by using neutron API per-request. Node "knows" means that neutron agents have this data stored in in-memory structures. In a case this "synchronization" is broken due a bug in software or (un)intentional change in neutron DB, I'd like to understand if the re-synchronization is possible. Right now, I know that L3 agent (I'm not sure if its working for all L3 agents) has periodic task that refreshes NIC information from neutron server. However, L2 agents don't have this mechanic. I don't know about agents that implement SDN.</span></div><div><span style="font-size:12.8000001907349px">So, I'm looking to learn how the current neutron implementation deals with that problem.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Fri, Mar 13, 2015 at 10:52 AM, Rossella Sblendido <span dir="ltr"><<a href="mailto:rsblendido@suse.com" target="_blank">rsblendido@suse.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On 03/07/2015 01:10 PM, Leo Y wrote:<br>
> What happens when neutron DB is updated to change network settings (e.g.<br>
> via Dashboard or manually) when there are communication sessions opened<br>
> in compute nodes. Does it influence those sessions? When the update is<br>
> propagated to compute nodes?<br>
<br>
Hi Leo,<br>
<br>
when you say "change network settings" I think you mean a change in the<br>
security group, is my assumption correct? In that case the Neutron<br>
server will notify all the L2 agent (they reside on each compute node)<br>
about the change. There are different kind of messages that the Neutron<br>
server sends depending on the type of the update,<br>
security_groups_rule_updated, security_groups_member_updated,<br>
security_groups_provider_updated. Each L2 agent will process the message<br>
and apply the required modification on the host. In the default<br>
implementation we use iptables to implement security group, so the<br>
update consists in some modifications of the iptables rules. Regarding<br>
the existing connections in the compute nodes they might not be affected<br>
by the change, which is a problem already discussed in this mail thread<br>
[1] and there's a patch in review to fix that [2].<br>
Hope that answers your question.<br>
<br>
cheers,<br>
<br>
Rossella<br>
<br>
[1]<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-October/049055.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-October/049055.html</a><br>
[2] <a href="https://review.openstack.org/#/c/147713/" target="_blank">https://review.openstack.org/#/c/147713/</a><br>
<br>
On 03/13/2015 04:10 AM, Kevin Benton wrote:<br>
> Yeah, I was making a bad assumption for the l2 and l3. Sorry about that.<br>
> It sounds like we don't have any protection against servers failing to<br>
> send notifications.<br>
><br>
> On Mar 12, 2015 7:41 PM, "Assaf Muller" <<a href="mailto:amuller@redhat.com" target="_blank">amuller@redhat.com</a><br>
> <mailto:<a href="mailto:amuller@redhat.com" target="_blank">amuller@redhat.com</a>>> wrote:<br>
><br>
><br>
><br>
> ----- Original Message -----<br>
> > > However, I briefly looked through the L2 agent code and didn't see a<br>
> > > periodic task to resync the port information to protect from a<br>
> neutron<br>
> > > server that failed to send a notification because it crashed or<br>
> lost its<br>
> > > amqp connection. The L3 agent has a period sync routers task<br>
> that helps in<br>
> > > this regard.<br>
><br>
> The L3 agent periodic sync is only if the full_sync flag was turned<br>
> on, which<br>
> is a result of an error.<br>
><br>
> > > Maybe another neutron developer more familiar with the L2<br>
> > > agent can chime in here if I'm missing anything.<br>
> ><br>
> > i don't think you are missing anything.<br>
> > periodic sync would be a good improvement.<br>
> ><br>
> > YAMAMAOTO Takashi<br>
> ><br>
> ><br>
> __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="">-- <br><div>Regards,<br> Leo<br>---------------------------------------------------------<br>I enjoy the massacre of ads. This sentence will slaughter ads without a messy bloodbath</div>
</span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div></div>