Open Stack

On Thu, Jul 21, 2016 at 1:16 PM, Ben Nemec <openstack at nemebean.com> wrote:
> 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.
>

Your feedback is really good, I'll do baby steps and add you as
reviewer when I'll start the work, so we can iterate on the things we
want to move and keep in place things we don't.
-- 
Emilien Macchi