Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

[Emilien Macchi]

On 01/24/2016 03:02 AM, Matthew Mosesohn wrote:
> 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!

I also think puppet-keystone would be a good place to start.
We have our Puppet Sprint [1] right now, maybe we could start working on it?

Let us know if you can participate or when do you plan to continue the
work on puppet-oslo; we can also provide any help that is needed.

Thanks,

[1] https://etherpad.openstack.org/p/puppet-happy-new-year-2016

> On Sun, Jan 24, 2016 at 7:05 AM, Xingchao Yu  > 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  >:
> 
> 
> 
> 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
> mailto:yux...@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 sin

Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

[Matt Fischer]

One thing that might be tough for operators is dealing with different
versions of openstack projects which require different versions of oslo.
Right now we have some stuff on Liberty, some stuff not. As we containerize
more services that's going to get even more true. Right now we can solve
this by using different versions of the puppet modules, but that will break
with a common module. To some extent we already have this problem with some
common stuff like openstacklib. I don't have a solution for this other than
being careful with deprecations, and I'll admit that this is just a
theoretical concern for now. As long as we stay within 1 release for our
modules we should probably be ok.

On Sun, Jan 24, 2016 at 1:02 AM, Matthew Mosesohn 
wrote:

> 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  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 :
>>
>>>
>>>
>>> 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 >> >>> > 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 op

Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

[Matthew Mosesohn]

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  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 :
>
>>
>>
>> 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 > >>> > 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-requ...@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-requ

Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

[Xingchao Yu]

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 :

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

Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

[Emilien Macchi]

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



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

[Doug Hellmann]

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

Doug

__
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

Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

[Cody Herriges]

Colleen Murphy wrote:
> On Tue, Jan 19, 2016 at 9:57 AM, Xingchao Yu  > 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?


-- 
Cody



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

[Colleen Murphy]

On Tue, Jan 19, 2016 at 9:57 AM, Xingchao Yu  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.

>
> And by the way, most of projects' requirements.txt
> and test-requirements.txt are maintained automatically by requirements
> project(https://github.com/openstack/requirements), they have the same
> version of oslo.* projects.
> So there maybe minor projects would need extra efforts.
>
> If projects seem to be converging together, maybe this isn't such an issue
anymore? I have no insight here.

Colleen
__
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

Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

[Xingchao Yu]

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

And by the way, most of projects' requirements.txt
and test-requirements.txt are maintained automatically by requirements
project(https://github.com/openstack/requirements), they have the same
version of oslo.* projects.
So there maybe minor projects would need extra efforts.

2016-01-19 20:44 GMT+08:00 Emilien Macchi :

> Hi,
>
> Adding [oslo] tag for more visibility.
>
> On 01/19/2016 05:01 AM, Xingchao Yu wrote:
> > Hi,  all:
> >
> > Recently I submit some patches for adding rabbit_ha_queues and
> > correct the section name of memcached_servers params to each modules,
> > then I find I just did repeated things:
> >
> >1. Adding one parameters which related to oslo.*  or authtoken to
> > all puppet modules
> >2. Correct section of parameters, move it from deprecated section
> > to oslo_* section, apply it on all puppet modules
> >
> >  We have more than 30+ modules for now, that means we have to repeat
> > 10+ or 20+ times if we want to do a simple change on oslo_* common
> configs.
> >
> >  Besides, the number of oslo_* section is growing, for example :
> >
> >- oslo_messaging_amqp
> >- oslo_messaging_rabbit
> >- oslo_middleware
> >- oslo_policy
> >- oslo_concurrency
> >- oslo_versionedobjects
> >...
> >
> > Now we maintain these oslo_* parameters separately in each modules,
> >  this has lead some problems:
> >
> > 1.  oslo_* params are inconsistent in each modules
> > 2.  common params explosion in each modules
> > 3.  no convenient way for managing oslo_* params
> >
> > When I was doing some work on keystone::resource::authtoken
> >  (https://review.openstack.org/#/c/266723/)
> >
> > Then I have a idea about adding puppet-oslo project, using a bunch
> > of define resources to unify oslo_* configs in each modules.
> >
> > I just write a prototype to show how does it works with oslo.cache:
> >
> >
> https://github.com/NewpTone/puppet-oslo/blob/master/manifests/cache.pp
> >
> > Please let me know your opinion on the same.
>
> We already talked about this topics during Vancouver Summit:
> https://etherpad.openstack.org/p/liberty-summit-design-puppet
>
> Real output is documented here:
> http://my1.fr/blog/puppet-openstack-plans-for-liberty/
>
> And I already initiated some code 8 months ago:
> https://github.com/redhat-cip/puppet-oslo
>
> At this time, we decided not to go this way because some OpenStack
> projects were not using the same version of oslo.*. sometimes.
> So it could have lead to something like:
> "nova using newest version of oslo messaging parameters comparing to
> murano" (that's an example, probably wrong...), so puppet-oslo would
> have been risky to use here.
> I would like to know from Oslo folks if we can safely configure Oslo
> projects the same way during a cycle (Ex: Mitaka, then N, etc) or if
> some projects are using too old versions of Oslo that makes impossible a
> consistent configuration across all OpenStack projects.
>
> So indeed, I'm still convinced this topic should be brought alive again.
> We would need to investigate with Oslo team if it makes sense and if we
> can safely do that for all our modules.
> If we have positive feedback, we can create the new module and
> refactorize our modules that will consume puppet-oslo.
> It will help a lot in keeping our modules consistent and eventually drop
> a lot of duplicated code.
>
> Thoughts?
>
> >
> > Thanks & Regards.
> >
> > --
> >  Xingchao Yu
> >
> >
> >
> >
> >
> __
> > 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
> >
>
> --
> Emilien Macchi
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/ma

Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

[Emilien Macchi]

Hi,

Adding [oslo] tag for more visibility.

On 01/19/2016 05:01 AM, Xingchao Yu wrote:
> Hi,  all:
> 
> Recently I submit some patches for adding rabbit_ha_queues and
> correct the section name of memcached_servers params to each modules,
> then I find I just did repeated things:
> 
>1. Adding one parameters which related to oslo.*  or authtoken to
> all puppet modules
>2. Correct section of parameters, move it from deprecated section
> to oslo_* section, apply it on all puppet modules
> 
>  We have more than 30+ modules for now, that means we have to repeat
> 10+ or 20+ times if we want to do a simple change on oslo_* common configs.
> 
>  Besides, the number of oslo_* section is growing, for example : 
> 
>- oslo_messaging_amqp
>- oslo_messaging_rabbit
>- oslo_middleware
>- oslo_policy
>- oslo_concurrency
>- oslo_versionedobjects
>...
>  
> Now we maintain these oslo_* parameters separately in each modules,
>  this has lead some problems:
> 
> 1.  oslo_* params are inconsistent in each modules
> 2.  common params explosion in each modules
> 3.  no convenient way for managing oslo_* params
> 
> When I was doing some work on keystone::resource::authtoken  
>  (https://review.openstack.org/#/c/266723/)
> 
> Then I have a idea about adding puppet-oslo project, using a bunch
> of define resources to unify oslo_* configs in each modules.
> 
> I just write a prototype to show how does it works with oslo.cache:
>   
> https://github.com/NewpTone/puppet-oslo/blob/master/manifests/cache.pp
>   
> Please let me know your opinion on the same.

We already talked about this topics during Vancouver Summit:
https://etherpad.openstack.org/p/liberty-summit-design-puppet

Real output is documented here:
http://my1.fr/blog/puppet-openstack-plans-for-liberty/

And I already initiated some code 8 months ago:
https://github.com/redhat-cip/puppet-oslo

At this time, we decided not to go this way because some OpenStack
projects were not using the same version of oslo.*. sometimes.
So it could have lead to something like:
"nova using newest version of oslo messaging parameters comparing to
murano" (that's an example, probably wrong...), so puppet-oslo would
have been risky to use here.
I would like to know from Oslo folks if we can safely configure Oslo
projects the same way during a cycle (Ex: Mitaka, then N, etc) or if
some projects are using too old versions of Oslo that makes impossible a
consistent configuration across all OpenStack projects.

So indeed, I'm still convinced this topic should be brought alive again.
We would need to investigate with Oslo team if it makes sense and if we
can safely do that for all our modules.
If we have positive feedback, we can create the new module and
refactorize our modules that will consume puppet-oslo.
It will help a lot in keeping our modules consistent and eventually drop
a lot of duplicated code.

Thoughts?

> 
> Thanks & Regards.
> 
> -- 
>  Xingchao Yu
> 
> 
> 
> 
> __
> 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
> 

-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital 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