nova team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

++

I'm all for using an existing solution if one exists. I've not looked
enough to make calls either way though. I want to figure out *what*
we are looking for in features to make those decisions.

-Eric

On Wed, Jul 28, 2010 at 01:37:18PM -0700, Monty Taylor wrote:
> So I know I haven't convinced everyone to love bzr yet ... but as they
> are a large python project with command line and config file options -
> and plugins - perhaps looking at the infrastructure/design they use
> might be a good idea?
> 
> Also, the work derks did with cement might be of help.
> 
> I believe both are designed to do things similar to how you are
> discussing them below (although different, of course - we're all python
> devs, there's no way we're going to actually do things the same. :) )
> 
> Monty
> 
> (what Eric is saying makes sense to me - but I don't have a whole bunch
> of stake either way here- I am a fan of reusing solutions that exist
> where possible though of course)
> 
> On 07/28/2010 01:24 PM, Eric Day wrote:
> > Hi Vish,
> > 
> > If we want to keep things modular and have runtime module selection
> > like you mention, we probably need to rethink flags. Using gflags
> > may not be an option unless we can somehow make 'undefok=' a global
> > option. In other project (that was not in Python, so no code to help),
> > the flow is:
> > 
> > * Enforce the use of module names in the options. For example, for
> >   generic queue module options use --queue.*, for libvirt module
> >   options, use --libvirt.*. If we want to make this seamless, we
> >   would probably need to use something else instead gflags or create
> >   a wrapper to enforce the required behavior.
> > 
> > * Import the core option manager, first thing that happens when
> >   starting a binary.
> > 
> > * Parse all options, separating each out into the modules they belong
> >   to. We don't know what is valid yet, but we can at least group by module.
> > 
> > * Load any required modules via normal 'import' lines. They can verify
> >   options for their module space.
> > 
> > * Have some core flags that specify which modules to load, for example,
> >   use rabbit vs fakerabbit. Then 'import' the selected optional modules.
> > 
> > * As optional modules load, let them verify the module namespace
> >   options just like the required modules did.
> > 
> > * Any options for modules that were not loaded are just ignored.
> > 
> > Thoughts on this? It has worked out quite well in the other C++ project
> > for me, and with Python it would be even easier to put together. :)
> > 
> > -Eric
> > 
> > On Wed, Jul 28, 2010 at 11:13:40AM -0700, Vishvananda Ishaya wrote:
> >>    I'm having some annoyances with gflags which I'd like to air out here.
> >>     Maybe we can come to a consensus about how to move forward with them.  I
> >>    find gflags annoying in the following ways:
> >>    a) flags are irritating for global settings.  Settings that apply to the
> >>    project as a whole have to be set in multiple places so that the binaries
> >>    all get them properly.  This can be fixed somewhat by a shared flagfile.
> >>     For example:
> >>    /etc/nova/nova-manage.conf:
> >>      --flagfile=/etc/nova/nova-common.conf # shared settings
> >>      --otherflag=true #manage specific settings
> >>    The problem here is that the shared settings can only include settings
> >>    that are imported by EVERY binary, or one of the binaries will choke.  So
> >>    if you have a flag that 4 of 5 binaries use, you either have to set it in
> >>    four flagfiles or put it in common with an ugly undefok= line.  This all
> >>    seems nasty to me.  Other possibilities include moving truly
> >>    common/settings related flags into the common flags.py so that they are
> >>    available to all binaries.  It all seems a bit hackish.
> >>    b) including files for flags only
> >>    There are places where we need access to a flag, but we aren't actually
> >>    making calls in the file.  Pyflakes and pylint complain about unused
> >>    imports.  Perhaps we fix this by moving these flags into common flagfile?
> >>    c) dependency injection
> >>    This is related to the issue above.  If we are dynamically loading
> >>    specific drivers (for example the auth driver or a datastore backend) as
> >>    specified by a flag, the import is often done later than the parent file
> >>    is imported.  Therefore using flags to configure settings for the driver
> >>    will fail, because the binary recognizing the flags is dependent on the
> >>    file that contains the flags being imported.  Workarounds here include
> >>    finding a different method for dependency injection, hacking flags to
> >>    search for flags in injected dependencies somehow, or configuring drivers
> >>    differently than the rest of the system.
> >>    So I see 3 options for moving forward
> >>    1) ditch gflags completely and use a different method for specifying
> >>    settings
> >>    2) use a combination of some kind of settings file for general
> >>    configuration, and flags for specific runtime settings/hacks
> >>    3) find good standard practices/workarounds for the above issues
> >>    Thoughts?
> >>    Vish
> > 
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~nova
> >> Post to     : nova@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~nova
> >> More help   : https://help.launchpad.net/ListHelp
> > 
> > 
> > _______________________________________________
> > Mailing list: https://launchpad.net/~nova
> > Post to     : nova@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~nova
> > More help   : https://help.launchpad.net/ListHelp
> >