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.
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
