My bet is first solve the problem, and then discuss how to improve the solution.
Specifying the DIB_REPOREF variables by hand on the puppet-module element in t-p-e will be an immediate improvement in stability terms. Then, it is fair to discuss how to automate the process to syncrhonise with puppet-openstack dependencies. Regards, On 16 December 2015 at 16:40, Jiří Stránský <[email protected]> wrote: > On 15.12.2015 19:12, Emilien Macchi wrote: > >> >> >> On 12/15/2015 12:23 PM, Jiří Stránský wrote: >> >>> On 15.12.2015 17:46, Emilien Macchi wrote: >>> >>>> For information, Puppet OpenStack CI is consistent for unit & functional >>>> tests, we use a single (versionned) Puppetfile: >>>> >>>> https://github.com/openstack/puppet-openstack-integration/blob/master/Puppetfile >>>> >>>> >>>> TripleO folks might want to have a look at this to follow the >>>> dependencies actually supported by upstream OR if you prefer surfing on >>>> the edge and risk to break CI every morning. >>>> >>>> Let me know if you're interested to support that in TripleO Puppet >>>> elements, I can help with that. >>>> >>> >>> Syncing tripleo-puppet-elements with puppet-openstack-integration is a >>> good idea i think, to prevent breakages like the puppet-mysql one >>> mentioned before. >>> >>> One thing to keep in mind is that the module sets in t-p-e and p-o-i are >>> not the same. E.g. recently we added the timezone module to t-p-e, and >>> it's not in the p-o-i Puppetfile. >>> >>> Also, sometimes we do have to go to non-openstack puppet modules to fix >>> things for TripleO (i don't recall a particular example but i think we >>> did a couple of fixes in non-openstack modules to allow us to deploy HA >>> with Pacemaker). In cases like this it would be helpful if we still had >>> the possibility to pin to something different than what's in >>> puppet-openstack-integration perhaps. >>> >>> >>> Considering the above, if we could figure out a way to have t-p-e behave >>> like this: >>> >>> * install the module set listed in t-p-e, not p-o-i. >>> >>> * if there's a ref/branch specified directly in t-p-e, use that >>> >>> * if t-p-e doesn't have a ref/branch specified, use ref/branch from p-o-i >>> >>> * if t-p-e doesn't have a ref/branch specified, and the module is not >>> present in p-o-i, use master >>> >>> * still honor DIB_REPOREF_* variables to pin individual puppet modules >>> to whatever wanted at time of building the image -- very useful for >>> temporary workarounds done either manually or in tripleo.sh. >>> >>> ...then i think this would be very useful. Not sure at the moment what >>> would be the best way to meet these points though, these are just some >>> immediate thoughts on the matter. >>> >> >> I think we shout not use puppet-openstack-integration per-se, it was >> just an example. >> >> Though we can take this project as reference to build a tool that >> prepare Puppet modules in TripleO CI. >> >> If you look at puppet-openstack-integration, we have some scripts that >> allow or not to use zuul-cloner with r10k, that's nice because it allows >> us to: >> * use depends-on puppet patches >> * if the end-user does not have zuul, it will git-clone, in tripleo case >> I think if DIB_REPOREF_* is set, let's use it >> * otherwise use git clone master. >> >> I would suggest also TripleO CI having a Puppetfile that would be gated >> (maybe in tripleo-ci repo?). >> > > We should probably put the pins somewhere else than tripleo-ci, because > we'd want dev environments to use the pinned versions too. Perhaps t-p-e is > the right place. > > The more i think about this the more i like the approach in Dan's patch -- > an extra element which will pin modules the DIB way. What we're lacking > here is a tool which could take a Puppetfile (specifically the Puppetfile > from puppet-openstack-integration) and produce the DIB_REPOREF variables > (perhaps ignoring all :ref => 'master' ones), so that we don't have to > track and update them by hand. > > I'm not sure if we absolutely need a Puppetfile for TripleO. The value > added is more in the pins themselves, not so much in syntax (Puppetfile vs. > DIB-style-file). We could use Puppetfile format too, but since we'll not be > able to use the one from puppet-openstack-integration directly (it's a > different set of modules), i don't see much value in switching over. > > Jirka > > > >> What do you think? >> >> >>> Jirka >>> >>> >>>> On 12/14/2015 02:25 PM, Dan Prince wrote: >>>> >>>>> On Fri, 2015-12-11 at 21:50 +0100, Jaume Devesa wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Today TripleO CI jobs failed because a new commit introduced on >>>>>> puppetlabs-mysql[1]. >>>>>> Mr. Jiri Stransky solved it as a temporally fix by pinning the puppet >>>>>> module clone to a previous >>>>>> commit in the tripleo-common project[2]. >>>>>> >>>>>> source-repositories puppet element[3] allows you to pin the puppet >>>>>> module clone as well by >>>>>> adding a reference commit in the source-repository-<element-name> >>>>>> file. In this case, >>>>>> I am talking about the source-repository-puppet-modules[4]. >>>>>> >>>>>> I know you TripleO guys are brave people that live dangerously in the >>>>>> cutting edge, but I think >>>>>> the dependencies to puppet modules not managed by the OpenStack >>>>>> community should be >>>>>> pinned to last repo tag for the sake of stability. >>>>>> >>>>>> What do you think? >>>>>> >>>>> >>>>> I've previously considered added a stable puppet modules element for >>>>> just this case: >>>>> >>>>> https://review.openstack.org/#/c/184844/ >>>>> >>>>> Using stable branches of things like MySQL, Rabbit, etc might make >>>>> sense. However I would want to consider following what the upstream >>>>> Puppet community does as well specifically because we do want to >>>>> continue using upstream openstack/puppet-* modules as well. At least >>>>> for our upstream CI. >>>>> >>>>> We also want to make sure our stable TripleO jobs use the stable >>>>> branches of openstack/puppet-* so we might need to be careful about >>>>> pinning those things too. >>>>> >>>>> Dan >>>>> >>>>> >>>>> I can take care of this. >>>>>> >>>>>> [1]: https://github.com/puppetlabs/puppetlabs-mysql/commit/bdf4d0f52d >>>>>> fc244d10bbd5b67efb791a39520ed2 >>>>>> [2]: https://review.openstack.org/#/c/256572/ >>>>>> [3]: https://github.com/openstack/diskimage-builder/tree/master/eleme >>>>>> nts/source-repositories >>>>>> [4]: https://github.com/openstack/tripleo-puppet-elements/blob/master >>>>>> /elements/puppet-modules/source-repository-puppet-modules >>>>>> >>>>>> -- >>>>>> Jaume Devesa >>>>>> Software Engineer at Midokura >>>>>> _____________________________________________________________________ >>>>>> _____ >>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>> Unsubscribe: [email protected]?subject:unsubs >>>>>> cribe >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> [email protected]?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Jaume Devesa Software Engineer at Midokura
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
