openstack team mailing list archive

[Akira Yoshiyama <akirayoshiyama@xxxxxxxxx>]

+1
 2011/11/02 2:38 "Brian Lamar" <brian.lamar@xxxxxxxxxxxxx>:

> 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@xxxxxxxxx>
> Sent: Monday, October 31, 2011 5:42pm
> To: "Joshua Harlow" <harlowja@xxxxxxxxxxxxx>
> Cc: "openstack" <openstack@xxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>