Hi Yong, I am confused by that bug, because it requests a change in devstack without the corresponding functionality being merged into quantum (unless I'm missing something).
In addition, I don't think we have agreement that the proposal the bug is linked to is the right way to solve the issue, as there are still unanswered questions. My main goal here is to get trunk devstack with quantum up and working as soon as possible, to make life easier for developers working on quantum. To that end, I've proposed a workaround to this issue for devstack: https://review.openstack.org/#change,6178 . I don't particularly like this fix, but it seems that either a fix like this, or a "git revert" of the original change is the best way to make sure devstack and quantum are back working in a timely fashion. I'm happy with alternative proposals, as long as they are easily reviewed and merged so we can get things working again. Thanks, Dan On Tue, Apr 3, 2012 at 5:18 AM, Yong Sheng Gong <gong...@cn.ibm.com> wrote: > I thin we can use bug: > quantum config is broken after being moved to /etc > https://bugs.launchpad.net/devstack/+bug/965199 > to revert it to original one. > Dean Troyer (dtroyer) is the assignee of this bug. > > What do you think of it? > > Regards, > > -----Dan Wendlandt <d...@nicira.com> <d...@nicira.com> wrote: ----- > > To: Yong Sheng Gong/China/IBM@IBMCN > From: Dan Wendlandt <d...@nicira.com> <d...@nicira.com> > Date: 04/03/2012 12:46PM > Cc: pot...@pothix.com, netstack@lists.launchpad.net > Subject: Re: About "add a more general function to read configure item in > plugins.ini file" > > > > On Sun, Apr 1, 2012 at 2:59 AM, Dan Wendlandt <d...@nicira.com> wrote: > >> Hi. >> >> Salvatore actually had a branch to merge plugins.ini with quantum.conf a >> while back, but we kept delaying because we felt that we were too close to >> a milestone release. >> Here's the change-set: https://review.openstack.org/#change,1415 >> >> I think that patch could now be simplified, as for Folsom I think we can >> just get rid of plugin.ini all together. >> >> It looks like the other part of your proposal is to include a path to the >> plugin's config file in plugin.ini/quantum.conf . This seems a bit tricky, >> as plugins may have more than one config file. Another option would be to >> have plugins put all of their config in a special section of quantum.conf . >> I think ultimately your goal is that someone running Quantum always has >> the option of explicitly defining where each config file is, rather than >> relaying on Quantum to look for config files in a set of allowed locations. >> I think that makes sense as a goal. >> > > Hi Yong, > > I'm not confident that specifying the plugin config file in quantum.conf > is a good approach. First, because it means that conf files are unlikely > to be able to be copied directly from one system to another. Second > because some plugins may have multiple config files (Cisco plugin may be an > example?). Having a flag to specify the configuration directory might > work. Another option would be to move toward plugins putting their config > in special sections in the quantum.conf itself (as I mentioned in my > review). > > In the absence of a short-term plan here, should be just revert the > original change to devstack that broke things? Its been over a week and > I've started getting emails about quantum + devstack being broken, which is > bad. > > Dan > > > > >> >> Dan >> >> >> On Thu, Mar 29, 2012 at 5:44 PM, Yong Sheng Gong <gong...@cn.ibm.com>wrote: >> >>> Hi Dan and Willian, >>> >>> >>> I wrote this letter to discuss review >>> https://review.openstack.org/#change,5849 . >>> >>> That bug described in https://bugs.launchpad.net/quantum/+bug/803086was >>> reported by Somik Behera on 2011-06-28 and Salvatore Orlando has been >>> working on it since 2011-10-13. It seems there is no much progress yet. >>> Moreover, I think quantum.conf should be able to integrate plugins.ini and >>> specify where the plugin provider's configuration file too. This way, >>> quantum-server --config_file=quantum.conf can weave all the configurations >>> together. >>> >>> Below is code for class QuantumManager(object): >>> >>> _instance = None >>> >>> def __init__(self, options=None, config_file=None): >>> # If no options have been provided, create an empty dict >>> if not options: >>> options = {} >>> >>> fix_path = lambda p: os.path.abspath(os.path.expanduser(p)) >>> if config_file: >>> config_file = fix_path(config_file) >>> config_file = [config_file] >>> >>> self.configuration_file = find_config_file(options, config_file, >>> CONFIG_FILE) >>> LOG.debug("Using plugins_ini %s", self.configuration_file) >>> if not 'plugin_provider' in options: >>> options['plugin_provider'] = \ >>> utils.get_plugin_from_config(self.configuration_file) >>> LOG.debug("Plugin location:%s", options['plugin_provider']) >>> >>> Just as shown by above codes, value for plugin_provider can be specified >>> in options instead of reading it frm plugins.ini. With the same way, we can >>> get provider's ini file location from options too. The options should be >>> content defined in quantum.conf after integration with command line options. >>> >>> This commit is just a compatible way to deal with independent >>> plugins.ini file. So if options do not contain provider's ini file >>> location, we can get it from the plugins.ini file. also plugins.ini should >>> be able to specified in quantum.conf if any. >>> >>> summary: quantum-server --config_file=quantum.conf. >>> >>> way 1: >>> quantum.conf: >>> plugins_ini = path/to/plugins.ini >>> >>> plugins.ini: >>> >>> provider = >>> quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPlugin >>> >>> provider_ini = /etc/quantum/ovs_quantum_plugin.ini >>> >>> or way 2: >>> >>> quantum.conf: >>> >>> plugin_provider = >>> quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPlugin >>> >>> provider_ini = /etc/quantum/ovs_quantum_plugin.ini >>> >>> my current commit is part of way 1, which is compatible with current >>> status quo. I am adding one general method to read item from plugins.ini. >>> >>> my fix to next bug is to implement way 1, which will chain all parts >>> together. my code is ready for it. If this commit can go, I will submit my >>> next commit. >>> >>> After way 1 is ok, way 2 is just on the way. >>> >>> Thanks >>> Yong Sheng Gong >>> >>> >> >> >> -- >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Dan Wendlandt >> Nicira Networks: www.nicira.com >> twitter: danwendlandt >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira Networks: www.nicira.com > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
