Open Stack

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 <emilien at redhat.com>:

> 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-request at 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-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/20160120/bd1f991f/attachment.html>