Open Stack

On 07/21/2016 11:31 AM, Steven Hardy wrote:
> On Wed, Jul 20, 2016 at 10:32:23PM -0400, Emilien Macchi wrote:
>> Hi,
>>
>> We're currently using tripleo-ci to store our test-environments files
>> (ie: multinode.yaml, etc).
>> To make it compatible with our different versions of TripleO, we have 2 options:
>>
>> * Duplicate templates and use bash conditionals in tripleo-ci scripts
>> to select which one we want at each release.
>> * Move them to THT (THT is branched & released).
>>
>> I would vote for option #2 for 2 reasons:
>> * we don't have to do complex conditionals in tripleo-ci
>> * we can easily consume it outside tripleo-ci (oooq one day?)
>> * we can easily make them evolve, when new composable services are
>> created for example.
> 
> +1 I agree it's probably best to move these to t-h-t, although we should
> clearly identify those environments which are specific to CI setups (such
> as where we override the number of workers to minimise resource usage).

Aren't they all specific to CI setups?  If not, they didn't belong in
tripleo-ci in the first place.
> 
> I think maintaining them in tripleo-ci will prove inconvenient in the long
> term, e.g https://review.openstack.org/#/c/338551/ is failing now because
> we now have coupling between the ControllerServices parameter default
> and the multinode HA job.

That's concerning.  I suppose it's a temporary problem while we finish
converting all of the existing services to composable format?  After
that service additions shouldn't be coupled as tightly.  They wouldn't
be tested by the multinode job until they're added to the list, but they
won't break the job either.

In any case, the ControllerServices bit of that template seems like a
candidate for including in t-h-t as environments/allinone.yaml or
something.  I would say that's generally useful to everyone so it's
sensible to include in t-h-t.

I'm less in favor of moving _everything_ out of tripleo-ci though.
tripleo-ci is essentially a user of t-h-t, which means it's the first
place we're going to find interface breakages.  If we do something that
breaks the existing "user" templates in tripleo-ci then we're causing
that same pain to our users and I think it's a good thing if it's also
painful for us.

So call this a +1/-1.  I'm good with moving the generic bits of the
multinode job out, but I think the rest should stay in tripleo-ci.

-Ben