<div dir="ltr">Hi, Emilien:<div><br></div><div><div class="gmail_extra"> Thanks for your efforts on this topic, I didn't attend V release summit and missed related discussion about puppet-oslo.</div><div class="gmail_extra"><br></div><div class="gmail_extra"> As the reason for not using a unified way to manage oslo_* parameters is there maybe exist different oslo_* version between openstack projects.</div><div class="gmail_extra"> </div><div class="gmail_extra"> 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.</div><div class="gmail_extra"><br></div><div class="gmail_extra"> It would be something like follows: (the map info is not true, just for example)</div><div class="gmail_extra"><br></div><div class="gmail_extra"> In Mitaka release</div><div class="gmail_extra"> puppet-nova maps to puppet-oslo with 8.0.0</div><div class="gmail_extra"> puppet-designate maps to puppet-oslo with 7.0.0</div><div class="gmail_extra"> puppet-<span style="font-size:14px">murano maps to puppet-oslo with 6.0.0</span></div><div class="gmail_extra"><span style="font-size:14px"><br></span></div><div class="gmail_extra"><span style="font-size:14px"> In Newton release</span></div><div class="gmail_extra"><div class="gmail_extra"> puppet-nova maps to puppet-oslo with 9.0.0</div><div class="gmail_extra"> puppet-designate maps to puppet-oslo with 9.0.0</div><div class="gmail_extra"> puppet-<span style="font-size:14px">murano maps to puppet-oslo with 7.0.0</span></div><div class="gmail_extra"><br></div><div class="gmail_extra"> And by the way, most of projects' requirements.txt and test-requirements.txt are maintained automatically by requirements project(<a href="https://github.com/openstack/requirements">https://github.com/openstack/requirements</a>), they have the same version of oslo.* projects. </div><div class="gmail_extra"> So there maybe minor projects would need extra efforts. </div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-19 20:44 GMT+08:00 Emilien Macchi <span dir="ltr"><<a href="mailto:emilien@redhat.com" target="_blank">emilien@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
Adding [oslo] tag for more visibility.<br>
<div><div class="h5"><br>
On 01/19/2016 05:01 AM, Xingchao Yu wrote:<br>
> Hi, all:<br>
><br>
> Recently I submit some patches for adding rabbit_ha_queues and<br>
> correct the section name of memcached_servers params to each modules,<br>
> then I find I just did repeated things:<br>
><br>
> 1. Adding one parameters which related to oslo.* or authtoken to<br>
> all puppet modules<br>
> 2. Correct section of parameters, move it from deprecated section<br>
> to oslo_* section, apply it on all puppet modules<br>
><br>
> We have more than 30+ modules for now, that means we have to repeat<br>
> 10+ or 20+ times if we want to do a simple change on oslo_* common configs.<br>
><br>
> Besides, the number of oslo_* section is growing, for example :<br>
><br>
> - oslo_messaging_amqp<br>
> - oslo_messaging_rabbit<br>
> - oslo_middleware<br>
> - oslo_policy<br>
> - oslo_concurrency<br>
> - oslo_versionedobjects<br>
> ...<br>
><br>
> Now we maintain these oslo_* parameters separately in each modules,<br>
> this has lead some problems:<br>
><br>
> 1. oslo_* params are inconsistent in each modules<br>
> 2. common params explosion in each modules<br>
> 3. no convenient way for managing oslo_* params<br>
><br>
> When I was doing some work on keystone::resource::authtoken<br>
> (<a href="https://review.openstack.org/#/c/266723/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/266723/</a>)<br>
><br>
> Then I have a idea about adding puppet-oslo project, using a bunch<br>
> of define resources to unify oslo_* configs in each modules.<br>
><br>
> I just write a prototype to show how does it works with oslo.cache:<br>
><br>
> <a href="https://github.com/NewpTone/puppet-oslo/blob/master/manifests/cache.pp" rel="noreferrer" target="_blank">https://github.com/NewpTone/puppet-oslo/blob/master/manifests/cache.pp</a><br>
><br>
> Please let me know your opinion on the same.<br>
<br>
</div></div>We already talked about this topics during Vancouver Summit:<br>
<a href="https://etherpad.openstack.org/p/liberty-summit-design-puppet" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/liberty-summit-design-puppet</a><br>
<br>
Real output is documented here:<br>
<a href="http://my1.fr/blog/puppet-openstack-plans-for-liberty/" rel="noreferrer" target="_blank">http://my1.fr/blog/puppet-openstack-plans-for-liberty/</a><br>
<br>
And I already initiated some code 8 months ago:<br>
<a href="https://github.com/redhat-cip/puppet-oslo" rel="noreferrer" target="_blank">https://github.com/redhat-cip/puppet-oslo</a><br>
<br>
At this time, we decided not to go this way because some OpenStack<br>
projects were not using the same version of oslo.*. sometimes.<br>
So it could have lead to something like:<br>
"nova using newest version of oslo messaging parameters comparing to<br>
murano" (that's an example, probably wrong...), so puppet-oslo would<br>
have been risky to use here.<br>
I would like to know from Oslo folks if we can safely configure Oslo<br>
projects the same way during a cycle (Ex: Mitaka, then N, etc) or if<br>
some projects are using too old versions of Oslo that makes impossible a<br>
consistent configuration across all OpenStack projects.<br>
<br>
So indeed, I'm still convinced this topic should be brought alive again.<br>
We would need to investigate with Oslo team if it makes sense and if we<br>
can safely do that for all our modules.<br>
If we have positive feedback, we can create the new module and<br>
refactorize our modules that will consume puppet-oslo.<br>
It will help a lot in keeping our modules consistent and eventually drop<br>
a lot of duplicated code.<br>
<br>
Thoughts?<br>
<span class=""><br>
><br>
> Thanks & Regards.<br>
><br>
> --<br>
> Xingchao Yu<br>
><br>
><br>
><br>
><br>
</span>> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<span class=""><font color="#888888"><br>
--<br>
Emilien Macchi<br>
<br>
</font></span><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><div><br></div><div class="gmail_signature"><div><br></div><div><br></div></div>
</div></div></div>