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?). 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 -- Emilien Macchi
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
