On 05/08/2015 07:17 AM, Doug Hellmann wrote:
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.
+1 - For the Keystone authentication options, I think it is important to
encapsulate this and hide the implementation from the other services as
much as possible, to make it easier to use all of the different types of
authentication supported by Keystone now and in the future. I would
think that something similar applies to the configuration of other
OpenStack services.
#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-----
__________________________________________________________________________
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
__________________________________________________________________________
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
