On Thu, Jul 21, 2016 at 01:30:37PM -0400, James Slagle wrote: > On Thu, Jul 21, 2016 at 1:16 PM, Ben Nemec <openst...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev