nova team mailing list archive

[Chris Behrens <chris.behrens@xxxxxxxxxxxxx>]

++

We should list requirements and look for what we need.

On Jul 28, 2010, at 2:41 PM, Monty Taylor wrote:

> On 07/28/2010 02:28 PM, Eric Day wrote:
>> ++
>>
>> 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.
>
> ++
>
>> 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
>>>>
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~nova
> Post to     : nova@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~nova
> More help   : https://help.launchpad.net/ListHelp