Hi, > I wanted to draw attention to my comments on this review, since several of > you aren't on there ( https://review.openstack.org/#/c/23360/). From > comments, it seems that the OVS plugin will fail if it is run with an > agent not configured with the "state-report" flag.
I totally agree with Dan. Thanks for raising it. I would like to share more detail. When L3NATAgent (without WithStateReport) is used, a router instance is not created. It leads to an failure of floating IP test in the gating test. The agent scheduler picks up a L3 agent from alive L3 agents and a list of L3 agents is constructed from state report. That is the reason L3 agent with state report is required at now. I am wondering a solution other than one using a flag. A key point is how to distinguish a situation all agents are dow from a situation there is no agents with state report. One idea is to the quantum server starts with non-scheduling mode (the legacy behavir) and switch to scheduling mode once a state report is received from an agent. It is just an idea and I haven't investigated it yet. Thanks, Akihiro >>>>> Date: Sun, 3 Mar 2013 09:12:09 -0800 >>>>> From: Dan Wendlandt <[email protected]> >>>>> Subject: [Quantum-core] compatibility with agents that do not have >>>>> 'statereport' configured > > Hi team, > > I wanted to draw attention to my comments on this review, since several of > you aren't on there ( > https://review.openstack.org/#/c/23360/). From comments, it seems that the > OVS plugin will fail > if it is run with an agent not configured with the "state-report" flag. > Yong, does this match > your understanding? If so, I think we are going to introduce a lot of > problems, especially sine > no such flag was required in Folsom. I'd much rather see a model where these > plugins can work > correctly even if state-report is not enabled in the agents (though of > course, without being able > to take advantage of the multi-agent capability). One obvious option would > be the core plugin to > get a flag indicating whether it should use state report as well. A better > option would probably > be to have the agents detect whether they should use state report, without a > flag at all (e.g., by > sending a message that will only be understood by a core plugin that expects > state report, and > otherwise falling back to not using state report). > > I'm open to thoughts there, but am worried that if we don't address this for > grizzly, we're going > to have a bit of a mess on our hands with people having trouble running > quantum. Thanks, > > Dan > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > [2 <text/plain; us-ascii (7bit)>] > -- > Mailing list: https://launchpad.net/~quantum-core > Post to : [email protected] > Unsubscribe : https://launchpad.net/~quantum-core > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
