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 : [email protected] >>>> Unsubscribe : https://launchpad.net/~nova >>>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~nova >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~nova >>> More help : https://help.launchpad.net/ListHelp >>> > _______________________________________________ Mailing list: https://launchpad.net/~nova Post to : [email protected] Unsubscribe : https://launchpad.net/~nova More help : https://help.launchpad.net/ListHelp
