On Tue, Nov 1, 2011 at 1:05 PM, Brian Lamar <brian.la...@rackspace.com> 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.
Sure, agreed. We've had a task in Glance to remove this coupling for a while now: https://bugs.launchpad.net/glance/+bug/815208 Happy to work on it, but it's not the highest priority right now :) > 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 Yup, I'd be in favour of the above (and below). -jay > $ 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" <jaypi...@gmail.com> > Sent: Monday, October 31, 2011 5:42pm > To: "Joshua Harlow" <harlo...@yahoo-inc.com> > Cc: "openstack" <openstack@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 <harlo...@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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
