Open Stack

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: OpenStack-dev-request at lists.openstack.org?subject:unsubs
>>> cribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>