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 <emil...@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-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/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