Open Stack

I would personally like to see Keystone get transitioned first, but it
really doesn't matter where we start if we reach the right goal in the end.
Since Emelien's work on refactoring all the providers for puppet-keystone,
it has become a test bed for project-wide features. I'm really excited to
see consistency in oslo config across services, so keep up the good work!

On Sun, Jan 24, 2016 at 7:05 AM, Xingchao Yu <yuxcer at gmail.com> wrote:

> Hi, all:
>
>     I spend some times to collect oslo.* versions of openstack
> projects(which has related puppet module), please check it in following
> table:
>
>     https://github.com/openstack/puppet-oslo#module-description
>
>     From the table, we can find most of oslo.* libraries are the same
> among the openstack projects(except aodh, gnocchi).
>
>     So from the table, we could use puppet-oslo to replace configuration
> of oslo.* in related modules gradually.
>
>     Thanks & Regards.
>
>
> 2016-01-21 23:58 GMT+08:00 Emilien Macchi <emilien at redhat.com>:
>
>>
>>
>> On 01/21/2016 08:15 AM, Doug Hellmann wrote:
>> > Excerpts from Cody Herriges's message of 2016-01-19 15:50:05 -0800:
>> >> Colleen Murphy wrote:
>> >>> On Tue, Jan 19, 2016 at 9:57 AM, Xingchao Yu <yuxcer at gmail.com
>> >>> <mailto:yuxcer at gmail.com>> wrote:
>> >>>
>> >>>     Hi, Emilien:
>> >>>
>> >>>          Thanks for your efforts on this topic, I didn't attend V
>> >>>     release summit and missed related discussion about puppet-oslo.
>> >>>
>> >>>          As the reason for not using a unified way to manage oslo_*
>> >>>     parameters is there maybe exist different oslo_* version between
>> >>>     openstack projects.
>> >>>
>> >>>          I have an idea to solve this potential problem,we can
>> maintain
>> >>>     several versions of puppet-oslo, each module can map to different
>> >>>     version of puppet-oslo.
>> >>>
>> >>>         It would be something like follows: (the map info is not true,
>> >>>     just for example)
>> >>>
>> >>>         In Mitaka release
>> >>>         puppet-nova maps to puppet-oslo with 8.0.0
>> >>>         puppet-designate maps to puppet-oslo with 7.0.0
>> >>>         puppet-murano maps to puppet-oslo with 6.0.0
>> >>>
>> >>>         In Newton release
>> >>>         puppet-nova maps to puppet-oslo with 9.0.0
>> >>>         puppet-designate maps to puppet-oslo with 9.0.0
>> >>>         puppet-murano maps to puppet-oslo with 7.0.0
>> >>>
>> >>> For the simplest case of puppet infrastructure configuration, which
>> is a
>> >>> single puppetmaster with one environment, you cannot have multiple
>> >>> versions of a single puppet module installed. This means you
>> absolutely
>> >>> cannot have an openstack infrastructure depend on having different
>> >>> versions of a single module installed. In your example, a user would
>> not
>> >>>  be able to use both puppet-nova and puppet-designate since they are
>> >>> using different versions of the puppet-oslo module.
>> >>>
>> >>> When we put out puppet modules, we guarantee that version X.x.x of a
>> >>> given module works with the same version of every other module, and
>> this
>> >>> proposal would totally break that guarantee.
>> >>>
>> >>
>> >> How does OpenStack solve this issue?
>> >>
>> >> * Do they literally install several different versions of the same
>> >> python library?
>> >> * Does every project vendor oslo?
>> >> * Is the oslo library its self API compatible with older versions?
>> >
>> > Each Oslo library has its own version. Only one version of each
>> > library is installed at a time. We use the global requirements list
>> > to sync compatible requirements specifications across all OpenStack
>> > projects to make them co-installable. And we try hard to maintain
>> > API compatibility, using SemVer versioning to indicate when that
>> > was not possible.
>> >
>> > If you want to have a single puppet module install all of the Oslo
>> > libraries, you could pull the right versions from the
>> upper-constraints.txt
>> > file in the openstack/requirements repository. That file lists the
>> > versions that were actually tested in the gate.
>>
>> Thanks for this feedback Doug!
>> So I propose we create the module in openstack namespace, please vote for:
>> https://review.openstack.org/#/c/270872/
>>
>> I talked with xingchao on IRC #puppet-openstack and he's doing
>> project-config patch today.
>> Maybe could we start with Nova, Neutron, Cinder, Glance, Keystone, see
>> how it works and iterate later with other modules.
>>
>> Thoughts are welcome,
>> --
>> Emilien Macchi
>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
>
> --
> Xingchao Yu
>
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160124/747000d2/attachment.html>