Re: [openstack-dev] [puppet] Puppet OpenStack PTL non-candidacy
Emilien, Thank you for your hard work and efforts to make Puppet-Openstack so great! 2016-09-11 9:53 GMT+08:00 Emilien Macchi : > Thank you all for all the kind words! I appreciate them a lot :-) > Just a note to avoid confusion, I'm not going anywhere, and I'll keep > focus on Puppet modules + TripleO like before. > Sorry but I'll still bother you when something breaks in OpenStack :-P > > Thanks again, > > On Sat, Sep 10, 2016 at 10:23 AM, Amrith Kumar wrote: > > Emilien, > > > > Great work over the past 18 months, it was a pleasure to work with you. > Thanks for all you've done! > > > > -amrith > > > >> -Original Message- > >> From: Emilien Macchi [mailto:emil...@redhat.com] > >> Sent: Friday, September 09, 2016 12:06 PM > >> To: OpenStack Development Mailing List openstack.org> > >> Subject: [openstack-dev] [puppet] Puppet OpenStack PTL non-candidacy > >> > >> Hi, > >> > >> I wrote a little blog post about the last cycle in PuppetOpenStack: > >> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/ > >> > >> I can't describe how much I liked to be PTL during the last 18 months > >> and I wouldn't imagine we would be where we are today when I started > >> to contribute on this project. > >> Working on it is something I really enjoy because we have interactions > >> with all OpenStack community and I can't live without it. > >> > >> However, I think it's time to pass the PTL torch for Ocata cycle. > >> Don't worry, I'll still be around and bother you when CI is broken ;-) > >> > >> Again, a big thank you for those who work with me, > >> -- > >> 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 > > > > -- > 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
Re: [openstack-dev] [puppet] Propose Sofer Athlan-Guyot (chem) part of Puppet OpenStack core
+1 to chem, nice work ! 2016-07-31 21:40 GMT+08:00 Sebastien Badia : > On Thu, Jul 28, 2016 at 11:16:17AM (-0400), Emilien Macchi wrote: > > You might not know who Sofer is but he's actually "chem" on IRC. > > He's the guy who will find the root cause of insane bugs, in OpenStack > > in general but also in Puppet OpenStack modules. > > Sofer has been working on Puppet OpenStack modules for a while now, > > and is already core in puppet-keystone. Many times he brought his > > expertise to make our modules better. > > He's always here on IRC to help folks and has excellent understanding > > at how our project works. > > > > If you want stats: > > http://stackalytics.com/?user_id=sofer-athlan-guyot&metric=commits > > I'm quite sure Sofer will make more reviews over the time but I have > > no doubt he fully deserves to be part of core reviewers now, with his > > technical experience and involvement. > > > > As usual, it's an open decision, please vote +1/-1 about this proposal. > > Hi! > > I'm not puppet-openstack core anymore, but I already worked with Sofer, and > I think it's very valuable for the team to have him as core! > > Thanks Sofer for all your work and engagement since the beginning! > > A big +1 for me! > > Seb > > -- > Sebastien Badia > > __ > 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 > > -- Email: yux...@gmail.com GitHub: https://github.com/NewpTone Blog:http://cnblogs.com/yuxc Weibo: http://www.weibo.com/nupta Now is better than never! __ 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-dev] [puppet] Discussion of PuppetOpenstack Project abbreviation
Hi, everyone: Do we need to give a abbreviation for PuppetOpenstack project? B/C it's really a long words when I introduce this project to people or writng article about it. How about POM(PuppetOpenstack Modules) or POP(PuppetOpenstack Project) ? I would like +1 for POM. Just an idea, please feel free to give your comment :D 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] Stepping down from Puppet Core
Mathieu, Thank you for everything you've done during the past years, your excellent work makes puppet community more better. And personally, you give me lots of guidance when I get started. Wish you all the best in the new journey. 2016-01-28 4:13 GMT+08:00 Mathieu Gagné : > Hi, > > I would like to ask to be removed from the core reviewers team on the > Puppet for OpenStack project. > > My day to day tasks and focus no longer revolve solely around Puppet and > I lack dedicated time to contribute to the project. > > In the past months, I stopped actively reviewing changes compared to > what I used to at the beginning when the project was moved to > StackForge. Community code of conduct suggests I step down > considerately. [1] > > I'm very proud of what the project managed to achieve in the past > months. It would be a disservice to the community to pretend I'm still > able or have time to review changes. A lot changed since and I can no > longer keep up or pretend I can review changes pedantically or > efficiently as I used to. > > Today is time to formalize and face the past months reality by > announcing my wish to be removed from the core reviewers team. > > I will be available to answer questions or move ownership of anything I > still have under my name. > > Wishing you the best. > > Mathieu > > [1] http://www.openstack.org/legal/community-code-of-conduct/ > > __ > 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
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 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
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 Mailin
[openstack-dev] [puppet] Proposal of adding puppet-oslo to OpenStack
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. 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
