Open Stack

On Tue, Aug 7, 2012 at 7:07 AM, Mark McLoughlin <markmc at redhat.com> wrote:

> On Tue, 2012-08-07 at 06:55 -0400, Doug Hellmann wrote:
> >
> > On Aug 7, 2012, at 3:08 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> >
> > > On Fri, 2012-08-03 at 13:40 -0400, Jay Pipes wrote:
> > >> I'd prefer smaller, reusable libs as well. Unfortunately, the decision
> > >> to use global CONF objects has essentially made the config module an
> > >> interdependency between all the other common code, so at a minimum,
> the
> > >> config module would need to be a dep in the other libs.
> > >
> > > Yes, most openstack-common modules depend on cfg.
> > >
> > > But this isn't because of the global config object. The dependency is
> > > there because we want to allow modules to define configuration options.
> >
> > Unfortunately it means the modules are going to be harder to reuse
> > outside of OpenStack because instead of providing a class-based API
> > that takes individual arguments that can come from another
> > application's config, or even a single config object as argument, the
> > global object needs to be initialized correctly.
>
> Yes, agree. But I don't see "enable reuse outside of OpenStack" as much
> of a priority here.
>
> Our focus should be on OpenStack's copy-and-paste technical debt rather
> than general re-usability. Allowing modules to add config parameters is
> a pragmatic approach to get us moving forward but, if we design the APIs
> well, we should be able to extend them later so that the config options
> can be overridden by API users.
>

Sure. I've been involved in a lot of projects that produce interesting code
that can't be used (easily) by anyone else because of tight coupling to
something simple like config or logging, so I'm sensitive to that when I
see it happening again. You're right that the priority needs to be on
internal reuse, though.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120807/3a86b6d7/attachment.html>