-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVS9HMAAoJEDehGd0Fy7uq24sH/j/ctaGaNbGdxyRCfBatIPbU Vk810yyMYzNH67s4Ku8LsEKvqMAoToEtnq/84ZXiUGUH65PtwGm9e6Nb54tkIHTE tPVjQSePC7omn97M5A4tb94b6h0TaLxWT+0oZjnto1Lk+/Q1tCYgCySClyF/CsmM 2CZvHRqRKWG1ytWhJuYrjymury4Xfgpcwt7MA69Nqun/7fwjSgFvvVdfVlln6VI+ 2Nx4AIFDyXVafvN7ZBIGkyqrWRsmyht3elvJg5JtxSu8gQbf3LVgbkTLREUccHDA 07/edo00ouAHMhKyYdvFimmjqr6gom5OqmpQqiw8TsFqFUDEXunTVil/v5W1dL8= =B85A -----END PGP SIGNATURE----- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev