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