/2015 04:48 AM
Subject:Re: [openstack-dev] [neutron] Generic question about
synchronizing neutron agent on compute node with DB
On Sun, Mar 15, 2015 at 22:37:59, Sławek Kapłoński wrote:
Maybe good idea for the beginning could be to implement some periodic
task
called
] Generic question about
synchronizing neutron agent on compute node with DB
On Sun, Mar 15, 2015 at 22:37:59, Sławek Kapłoński wrote:
Maybe good idea for the beginning could be to implement some periodic
task
called from agent to check db config and compare it with real state
Hello,
Thanks. I didn't find it before.
When we will upgrade our infra we will see if this problem will still present.
I hope that this was due to that bug maybe and will be fixed then :)
--
Pozdrawiam / Best regards
Sławek Kapłoński
sla...@kaplonski.pl
Dnia poniedziałek, 16 marca 2015
On Sun, Mar 15, 2015 at 22:37:59, Sławek Kapłoński wrote:
Maybe good idea for the beginning could be to implement some periodic
task
called from agent to check db config and compare it with real state on
host?
What do You think? Or maybe I'm competly wrong with such idea and it
should be
On 14 March 2015 at 11:19, Sławek Kapłoński sla...@kaplonski.pl wrote:
Hello,
I'm using ovs agents with L2 population mechanism in ML2 plugin. I noticed
that sometimes agents don't receive proper RPC to add new vxlan tunnel
openflow rules and then vxlan network between some compute nodes not
The L2 agent, for instance, has a logic to perform full synchronisations
with the server.
These happens in two cases:
1) upon agent restart, as some messages from the server side might have
gone lost
2) whenever a failure is detected on the agent side (this is probably a bit
too conservative).
Hello,
Dnia niedziela, 15 marca 2015 17:45:05 Salvatore Orlando pisze:
On 14 March 2015 at 11:19, Sławek Kapłoński sla...@kaplonski.pl wrote:
Hello,
I'm using ovs agents with L2 population mechanism in ML2 plugin. I noticed
that sometimes agents don't receive proper RPC to add new vxlan
Hi slawek,
may be you're hitting this l2pop bug :
https://bugs.launchpad.net/neutron/+bug/1372438
On Sun, Mar 15, 2015 at 11:37 PM, Sławek Kapłoński sla...@kaplonski.pl
wrote:
Hello,
Dnia niedziela, 15 marca 2015 17:45:05 Salvatore Orlando pisze:
On 14 March 2015 at 11:19, Sławek Kapłoński
Hello Rossella,
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
Hello,
I'm using ovs agents with L2 population mechanism in ML2 plugin. I noticed
that sometimes agents don't receive proper RPC to add new vxlan tunnel
openflow rules and then vxlan network between some compute nodes not working.
I'm now using still havana release but want to upgrade to Juno.
On 03/07/2015 01:10 PM, Leo Y wrote:
What happens when neutron DB is updated to change network settings (e.g.
via Dashboard or manually) when there are communication sessions opened
in compute nodes. Does it influence those sessions? When the update is
propagated to compute nodes?
Hi Leo,
What does it mean under if that notification is lost, the agent will
eventually resynchronize? Is it proven/guaranteed? By what means?
Can you, please the process with more details? Or point me to resources
that describe it.
Thank you
On Mon, Mar 9, 2015 at 2:11 AM, Kevin Benton
- Original Message -
However, I briefly looked through the L2 agent code and didn't see a
periodic task to resync the port information to protect from a neutron
server that failed to send a notification because it crashed or lost its
amqp connection. The L3 agent has a period
If there are any errors on the agent connecting to the message bus or
retrieving messages, an exception will be thrown in the main rpc_loop,
which will be caught and a sync flag will be set to true, which will
trigger the sync on the next loop.
However, I briefly looked through the L2 agent code
Yeah, I was making a bad assumption for the l2 and l3. Sorry about that. It
sounds like we don't have any protection against servers failing to send
notifications.
On Mar 12, 2015 7:41 PM, Assaf Muller amul...@redhat.com wrote:
- Original Message -
However, I briefly looked through
However, I briefly looked through the L2 agent code and didn't see a
periodic task to resync the port information to protect from a neutron
server that failed to send a notification because it crashed or lost its
amqp connection. The L3 agent has a period sync routers task that helps in
this
Port changes will result in an update message being sent on the AMQP
message bus. When the agent receives it, it will affect the communications
then. If that notification is lost, the agent will eventually resynchronize.
So during normal operations, the change should take effect within a few
Hello,
What happens when neutron DB is updated to change network settings (e.g.
via Dashboard or manually) when there are communication sessions opened in
compute nodes. Does it influence those sessions? When the update is
propagated to compute nodes?
Thank you
18 matches
Mail list logo