+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" <rmegg...@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-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
__________________________________________________________________________
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
