Open Stack

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