Open Stack

The only code that is used from gflags ls ReadFlagsFromFiles which recursively reads flags from files and converts them into args (removing comments). We could rewrite or copy this code and remove the gflags dependency, but if we are moving towards a config file instead of a flag file we will be specifying these using a different config parser so it makes sense to leave it for now.

Vish

On Nov 1, 2011, at 10:05 AM, Brian Lamar wrote:

> From what I understand, Nova is in the middle of a transition from gflags to optparse.
> 
> It's difficult to tell exactly what is going on, but the flags file is still being read by gflags and then optparse seems to take over from there. Regardless, both libraries are still being used and the scenario that Joshua bring up is still a concern.
> 
> I'm all for switching to `optparse` but it's going to be a heck of a transition.
> 
> I worry about the the tight coupling that Glance has with `paste` and I would caution against Nova coupling with `paste` in a similar fashion.
> 
> IMO if the API wants to use `paste.deploy` as a configuration mechanism that is great but the entire project should not be configured out of a paste config file just because they happen to use INI syntax.
> 
> I'd like to treat paste deploy files as code and our configuration files as configuration files. (This will be the biggest point of controversy?)
> 
> As an example, without thinking too much about it, we could have:
> 
> $ cat /etc/nova/nova.conf
> 
> [logging]
> driver=nova.log.drivers.SyslogDriver
> syslog_dev=/dev/log
> verbose=true
> 
> [nova-network]
> manager=nova.network.quantum.QuantumManager
> vlan_interface=eth1
> 
> [nova-api]
> driver=nova.api.drivers.PasteDriver
> config=/etc/nova/api-paste.ini
> pipeline=osapi-with-keystone
> 
> 
> $ cat /etc/nova/api-paste.ini
> 
> ...
> 
> [pipeline:osapi]
> pipeline = faultwrap noauth ratelimit serialize extensions osapiapp11
> 
> [pipeline:osapi-with-keystone]
> pipeline = faultwrap keystone-auth ratelimit serialize extensions osapiapp11
> 
> ...
> 
> 
> 
> 
> -----Original Message-----
> From: "Jay Pipes" <jaypipes at gmail.com>
> Sent: Monday, October 31, 2011 5:42pm
> To: "Joshua Harlow" <harlowja at yahoo-inc.com>
> Cc: "openstack" <openstack at lists.launchpad.net>
> Subject: Re: [Openstack] Gflags / conf -> common?
> 
> Hi!
> 
> GFlags has now been removed, AFAIK. The flags module has an
> optparse-based emulator for GFlags to ease transition for Nova joining
> the rest of the OpenStack core project implementations' use of
> standard config files/Paste.Deploy.
> 
> Cheers,
> -jay
> 
> On Mon, Oct 31, 2011 at 5:08 PM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:
>> Hi all,
>> 
>> I was wondering if there is any plans in essex to standardize either using
>> gflags or using configuration files for these types of settings.
>> One of the complaints that I receive a lot with gflags is that by including
>> a python file, u automatically inject all of its flags (even if they are not
>> used) into gflags (since its global).
>> Thus say u are just using the nova-compute run time, but that itself
>> includes say “flags.py” which itself seems to be a common area for flags
>> that may or may not be used by that runtime. Similarly if a file is imported
>> has say 1 method used by the calling code but itself defines 10 flags (for
>> its components) then those 10 flags get injected. This makes it very
>> confusing to figure out what should be set (or what could be set).
>> 
>> Has there been any thought on fixing this (or making a standard
>> recommendation that subprojects can follow) that would avoid this problem?
>> I could imagine fixes being in the code structure itself (having said 1
>> method stated above not be in a file what pulls in other code that defines
>> 10 flags) or another type of configuration mechanism?
>> I think this was mentioned at the conference, but not sure what came out of
>> that :-)
>> 
>> -Josh
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp