Open Stack

On Thu, Jul 21, 2016 at 01:30:37PM -0400, James Slagle wrote:
> 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).

This is true, but in this case I think we could convert the environment
defining ControllerServices for the multinode job to a more generic
sample environment, e.g environments/all_in_one.yaml or something?

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

Yes, I think both of these will be possible, the additions requirement will
be enabled by this heat spec, which Rabi is currently implementing:

https://review.openstack.org/#/c/330414/

When that lands, we'll be able to do something like this to append to e.g
ControllerServices in the various environment files:

https://etherpad.openstack.org/p/tripleo-heat-merge-strategies

For the ControllerServicesRemovals it's a bit less clear - we definitely
could add a blacklist parameter like this (which again could be appended
via the environment merging described above), and then use yaql to
calculate the subset from ControllerServices, but I'm thinking if there's a
cleaner way (perhaps an extra step beyond the "add" merge strategy, or
another heat function that can calculate the subset, "list_subtract"?).

Thanks,

Steve