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