Open Stack

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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev