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 [email protected] Dnia poniedziałek, 16 marca 2015 00:14:57 Mathieu Rohon pisze: > 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 <[email protected]> > > 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 <[email protected]> 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 > > > > working. > > > > I'm now using still havana release but want to upgrade to Juno. I was > > > > checking > > > > Juno code in l2 population mech driver and ovs plugin and I didn't > > > > find > > > > anything like periodic check if openflow rules are proper set or maybe > > > > resynced. > > > > Maybe it would be also good idea to add something like that to ovs > > > > agent? > > > > > It would surely be a good idea to add some form of reliability into > > > communications between server and agents. > > > So far there are still several instances where the server sends a "fire > > > > and > > > > > forget" notification to the agent, and does not take any step to ensure > > > > the > > > > > state change associated with that notification has been actually applied > > > > to > > > > > the agent. This applies also to some messages from the agent side, such > > > > as > > > > > status change notifications. > > > > 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 > > done in different way? > > > > > This is something that can be beneficial any neutron implementation > > > which > > > depends on one or more agents, not just for those using the ovs/linux > > > bridge agents with the l2-population driver. > > > > Probably yes, but I had this problem only with this l2-population driver > > so > > far and that's why I wrote about it :) > > > > -- > > Pozdrawiam / Best regards > > Sławek Kapłoński > > [email protected] > > > > > Salvatore > > > > > > > -- > > > > Pozdrawiam / Best regards > > > > Sławek Kapłoński > > > > [email protected] > > > > > > > > Dnia piątek, 13 marca 2015 11:18:28 YAMAMOTO Takashi pisze: > > > > > > 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 regard. Maybe another neutron developer more familiar with > > > > the L2 > > > > > > > > agent can chime in here if I'm missing anything. > > > > > > > > > > i don't think you are missing anything. > > > > > periodic sync would be a good improvement. > > > > > > > > > > YAMAMAOTO Takashi > > > > __________________________________________________________________________ > > > > > > > OpenStack Development Mailing List (not for usage questions) > > > > > > > > > Unsubscribe: > > > > [email protected]?subject:unsubscribe > > > > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > > > > > > OpenStack Development Mailing List (not for usage questions) > > > > > > Unsubscribe: > > [email protected]?subject:unsubscribe > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
