Open Stack

Excerpts from Ben Nemec's message of 2015-05-07 15:57:48 -0500:
> I don't know much about the puppet project organization so I won't
> comment on whether 1 or 2 is better, but a big +1 to having a common
> way to configure Oslo opts.  Consistency of those options across all
> services is one of the big reasons we pushed so hard for the libraries
> to own their option definitions, so this would align well with the way
> the projects are consumed.
> 
> - -Ben

Well said, Ben.

Doug

> 
> On 05/07/2015 03:19 PM, Emilien Macchi wrote:
> > Hi,
> > 
> > I think one of the biggest challenges working on Puppet OpenStack 
> > modules is to keep code consistency across all our modules (~20). 
> > If you've read the code, you'll see there is some differences
> > between RabbitMQ configuration/parameters in some modules and this
> > is because we did not have the right tools to make it properly. A
> > lot of the duplicated code we have comes from Oslo libraries 
> > configuration.
> > 
> > Now, I come up with an idea and two proposals.
> > 
> > Idea ====
> > 
> > We could have some defined types to configure oslo sections in
> > OpenStack configuration files.
> > 
> > Something like: define oslo::messaging::rabbitmq( $user, $password 
> > ) { ensure_resource($name, 'oslo_messaging_rabbit/rabbit_userid',
> > {'value' => $user}) ... }
> > 
> > Usage in puppet-nova: ::oslo::messaging::rabbitmq{'nova_config': 
> > user     => 'nova', password => 'secrete', }
> > 
> > And patch all our modules to consume these defines and finally
> > have consistency at the way we configure Oslo projects (messaging,
> > logging, etc).
> > 
> > Proposals =========
> > 
> > #1 Creating puppet-oslo ... and having oslo::messaging::rabbitmq,
> > oslo::messaging::qpid, ..., oslo::logging, etc. This module will be
> > used only to configure actual Oslo libraries when we deploy
> > OpenStack. To me, this solution is really consistent with how 
> > OpenStack works today and is scalable as soon we contribute Oslo 
> > configuration changes in this module.
> > 
> > #2 Using puppet-openstacklib ... and having
> > openstacklib::oslo::messaging::(...) A good thing is our modules
> > already use openstacklib. But openstacklib does not configure
> > OpenStack now, it creates some common defines & classes that are
> > consumed in other modules.
> > 
> > 
> > I personally prefer #1 because: * it's consistent with OpenStack. *
> > I don't want openstacklib the repo where we put everything common.
> > We have to differentiate *common-in-OpenStack* and
> > *common-in-our-modules*. I think openstacklib should continue to be
> > used for common things in our modules, like providers, wrappers,
> > database management, etc. But to configure common OpenStack bits
> > (aka Oslo©), we might want to create puppet-oslo.
> > 
> > As usual, any thoughts are welcome,
> > 
> > Best,
> > 
> > 
> > 
> > ______________________________________________________________________
> ____
> >
> > 
> OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> -----BEGIN PGP SIGNATURE-----
>