← Back to team overview

openstack team mailing list archive

Re: cfg usage - option registration, global objects

 

On 05/29/2012 04:04 AM, Mark McLoughlin wrote:
Hey,

I had the chance to discuss the "global conf" issue with a good number
of folks at the design summit and the conclusion I came away with was
that opinions range from "meh, it's fairly inelegant but I don't care
much either way" to "I actually like the simplicity" to "we use global
conf, it works and we're not changing".

Indeed, at the "common configuration patterns", there was very little in
the way of opinion expressed at all:

   http://etherpad.openstack.org/FolsomCommonConfigPatterns

Given that my goal here is to establish a common pattern used by all
projects, that both Nova and Keystone uses global conf and there isn't a
huge amount of interest in moving away from it, I'm proposing adding
support for it to openstack-common:

   https://blueprints.launchpad.net/openstack-common/+spec/cfg-global-object

Adopting this pattern across all projects will actually help
openstack-common more generally. For example, Russell is moving the RPC
code into openstack-common and it has a bunch of configuration options.
If it can assume a global configuration object, things become much
easier.

Unfortunately, what this leads to is interdependencies between the openstack-common-rpc code and the openstack-common-cfg code. :( Now, if someone wants to use the openstack RPC code in their own project, they have to switch their way of configuring stuff to use global config objects. Tight coupling means less adherence to the "do one thing and do it well" mantra of *nix utilities and libraries and in general isn't good software design.

I've posted patches to openstack-common, Nova, Glance and Keystone:

   https://review.openstack.org/#/q/status:open+branch:master+topic:bp/cfg-global-object,n,z

Yes, I've noticed. :) I'm not a fan at all, but that said, it is more important to have consistency among the core projects IMHO, than to be ideologically pure on this point.

Hopefully others who are being ideologically stubborn about things like "the multiprocessing library is broken" can see to also being less stubborn so certain patches can move forward in code review...

Best,
-jay


References