Open Stack

On Thu, Sep 28, 2017 at 8:04 AM, Marios Andreou <mandreou at redhat.com> wrote:
>
>
> On Thu, Sep 28, 2017 at 9:50 AM, mathieu bultel <mbultel at redhat.com> wrote:
>>
>> Hi,
>>
>>
>> On 09/28/2017 05:05 AM, Emilien Macchi wrote:
>> > I was reviewing https://review.openstack.org/#/c/487496/ and
>> > https://review.openstack.org/#/c/487488/ when I realized that we still
>> > didn't have any test coverage for minor updates.
>> > We never had this coverage AFICT but this is not a reason to not push
>> > forward it.
>> Thank you for the review and the -2! :)
>> So I'm agree with you, we need CI coverage for that part, and I was
>> wondering how I can put quickly a test in CI for the minor update.
>> But before that, just few things to take in account regarding those
>> reviews:
>>
>
> agree on the need for the ci coverage, but disagree on blocking this. by the
> same logic we should not have landed anything minor update related during
> the previous cycle. This is the very last part for
> https://bugs.launchpad.net/tripleo/+bug/1715557 - wiring up the mechanism
> into client and what's more matbu has managed to do it 'properly' with a
> tripleo-common mistral action wired up to the tripleoclient cli.
>
> I don't think its right we don't have coverage but I also don't think its
> right to block these last patches,

Yeah I agree - FWIW we have discussed this before, and AIUI the plan was:

1 - Get multinode coverage of an HA deployment with more than on
controller (e.g the 3nodes job) but with containers enabled
2- Implement a rolling minor update test based on that
multi-controller HA-with-containers test

AFAIK we're only starting to get containers+pacemaker CI scenarios
working with one controller, so it's not really reasonable to block
this, since that is a prerequisite to the multi-controller test, which
is a prerequisite to the rolling update test.

Personally I think we'd be best to aim directly for the rolling update
test in CI, as doing a single node minor update doesn't really test
the most important aspect (e.g zero downtime).

The other challenge here is the walltime relative to the CI timeout -
we've been running into that for the containers upgrade job, and I
think we need to figure out optimizations there which may also be
required for minor update testing (maybe we can work around that by
only updating a very small number of containers, but that will reduce
the test coverage considerably?)

I completely agree we need this coverage, and honestly we should have
had it a long time ago, but we need to make progress on this last
critical blocker for pike, while continuing to make progress on the CI
coverage (which should certainly be a top priority for the Lifecycle
squad, as soon as we have this completely new-for-pike minor updates
workflow fully implemented and debugged).

Thanks,

Steve