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.

I'm fine to move them.

But I agree with you that we should be careful about how that might
mask issues in our user experience. ControllerServices is like
ServiceNetMap in this regard. They are both really big large value
lists. As a user, if you choose to modify that, it's now up to you to
keep your modifications in sync with any changes done to the default
value. If we end up adding a new service that ends up being required,
you're not going to have that in your list if you've overridden it (as
the swift patch shows).

Perhaps we could add some additional interfaces such as
ControllerServicesAdditions/ControllerServicesRemovals that operated
on the default value of ControllerServices somehow.

-- 
-- James Slagle
--