[openstack-dev] [tripleo] CI scenarios design - how to add more services

Gabriele Cerami gcerami at redhat.com
Fri Nov 25 12:22:36 UTC 2016

On 22 Nov, Emilien Macchi wrote:
> 1) Re-use experience from Puppet OpenStack CI and have environments
> that are in a branched repository.
> a) Move CI environments and pingtest into
> tripleo-heat-templates/environments/ci/(scenarios|pingtest). This repo
> is branched and we could add a README to explain these files are used
> in CI and we don't guarantee they would work outside TripleO CI tools.

I would consider it a big step for tht repo, to include test specific
code in it. *Upstream CI specific code* even

> b) Branch tripleo-ci repository. Personally I don't like this solution
> because a lot of patches in this repo are not related to OpenStack
> versions, which means we would need to backport most of the things
> from master.

I agree, we should be able to branch only the options and configuration,
not the entire process. Process is constantly changing and it would be
a pain to backport all this changes.

> 2) Introduce branch-based scenario tests -
> https://review.openstack.org/#/c/396008/
> It duplicates a lot of code and it's imho not really effective, though
> this solution would correctly works.

I don't understand why you consider this code duplication and don't
consider branching code duplication too.
With branches you're duplicating even if you don't see all the
duplicates at once. Consider that with this method it could be easier to
"backport" a scenario modification, since you can do everything with a
single commit.
I would prefer a different format tough

> 3) Introduce a new scenario each time we have new services (like we
> did with scenario004).

This doesn't scale well, we would have to be able to select which
scenario to run anyway

I have one last consideration to make.
With the transition to quickstart, we're effectively moving the process
part of tripleo-ci to another repo.
After the transition we could consider tripleo-ci more options and
configuration that process, and the we could start branching it, without
all the drawbacks we considered here.

More information about the OpenStack-dev mailing list