| Thread Previous • Date Previous • Date Next • Thread Next |
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
| Thread Previous • Date Previous • Date Next • Thread Next |
