Open Stack

On Fri, Nov 25, 2016 at 7:22 AM, Gabriele Cerami <gcerami at redhat.com> wrote:
> 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
> templates/$BRANCH/scenario-001.yaml
> test-environments/$BRANCH/scenario-001.yaml

With branches, we might see the "duplication" as a simple backport.
Remember, we don't backport features, so once we cut a release, we
should not backport any change in our scenarios environments, since we
don't had features (again).

Which means, once we implement the CI templates in THT, we shouldn't
backport anything but bugfixes in stable branches. Scenarios will
evolve as we add features in master (ex: barbican service, etc).
That said, 2) would also work. It's just a lot of files and lines of
code in tripleo-ci, that could live in a branched repo (THT), which is
why I took the simplest solution with 1)a).

>> 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.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi