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/803086 was >> 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
