On Sun, Mar 3, 2013 at 9:55 AM, Akihiro MOTOKI <[email protected]> wrote:
> 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. > Yes, that's exactly the kind of model that I would like to see as well. dan > > 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 > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
