Open Stack

+1 I agree we should do this, etc., etc.

I don’t have a strong preference for #1 or #2, either.  But I do think #1 
is slightly more complicated from a deployer/operator perspective.  It’s 
another module I have to manage, pull in, etc.  Granted this is a trivial 
amount of incremental work.

I confess I am not super familiar with openstacklib, but I don’t 
understand why "We have to differentiate *common-in-OpenStack* and 
*common-in-our-modules*.”  To me, openstacklib is for _anything_ that’s 
common.  Maybe you could expand upon your thinking on this a little more, 
just so it’s a little more explicit?

Since others are not chomping at the bit to chime in here, I guess there 
is probably not many major preferences on this.  I would be happy with 
getting this done, regardless of how it’s implemented.

Thanks,
Mike






On 5/8/15, 7:50 AM, "Rich Megginson" <rmeggins at redhat.com> wrote:

>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
>
>
>__________________________________________________________________________
>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