openstack team mailing list archive

[Mark McLoughlin <markmc@xxxxxxxxxx>]

Hi Monty,

On Mon, 2011-11-28 at 08:06 -0800, Monty Taylor wrote:
> Hey Mark!
> 
> On 11/28/2011 07:09 AM, Mark McLoughlin wrote:
> > Hey,
> > 
> > I've just posted this blueprint:
> > 
> >   https://blueprints.launchpad.net/openstack-common/+spec/common-config
> >   http://wiki.openstack.org/CommonConfigModule
> > 
> > The idea is to unify option handling across projects with this new API.
> > The module would eventually (soon?) live in openstack-common.
> 
> Awesome. So - whaddya think about making openstack-common an
> installable/consumable module?

Absolutely, I basically decided to poke at this because I thought it
would help kickstart openstack-common again.

> > Code and unit tests here:
> > 
> >   https://github.com/markmc/nova/blob/common-config/nova/common/cfg.py
> >   https://github.com/markmc/nova/blob/common-config/nova/tests/test_cfg.py
> > 
> > And patches to make both Glance and Nova use it are on the
> > 'common-config' branches of my github forks:
> > 
> >   https://github.com/markmc/nova/commits/common-config
> >   https://github.com/markmc/glance/commits/common-config
> 
> Similar to the above comment, I'd love to avoid needing to copy this in
> to 6 different projects.
> 
> > Glance and (especially) Nova still need a bunch of work to be fully
> > switched over to the new model, but both trees do actually appear to
> > work fine and could be merged now.
> > 
> > Lots of detail in there, but all comments are welcome :)
> 
> I'd really love to see the openstack-common module follow the model
> we're working on with python-*client - which would make it something we
> can pip install.

Yep, definitely.

> Then, we can add a git url to the pip-requires file so that dev venvs
> always pick up the latest version.

Yes, but not at the cost of maintaining proper API compatibility - e.g.
if it's installed as a normal python library, you don't want to get into
a situation where you can't e.g. use newer keystone with older nova
because they require different versions of the API that no single
version of the library supports.

> Just a thought- but I'd be happy to help explore plumbing options here.
> 
> Monty
> 
> PS. Alternately, the story in the python world in general for command
> line parsing combined with config file parsing in a way that works
> sensibly is woefully underserved. Perhaps rather than having this as a
> part of openstack-common, we just make it an actual general option
> parsing library and then try to get it eventually promoted into the
> standard lib? The problem you're talking about in the blueprint is
> certainly not specific to us. (hell, I was thinking about adding a
> possible global config file to git-review, and then vomited when I
> realized I was going to have to do the plumbing twice)

Yeah, it's a fair point and I had thought about it. I'm thinking I'd
like to see how it works out in OpenStack first before trying to get it
more broadly adopted.

Also, the same may well be true of most things that go into
openstack-common - e.g. we may well have had tools/rfc.sh in
openstack-common and then figured out to get it out there more widely as
git-review.

Cheers,
Mark.