Open Stack

On Thu, Sep 28, 2017 at 3:23 AM, Steven Hardy <shardy at redhat.com> wrote:

> 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?)
>

OK.. I think the solution is to start migrating these jobs to RDO Software
Factory third party testing.

Here is what I propose:
1. Start with an experiment check job
https://review.rdoproject.org/r/#/c/9823/
This will help us confirm that everything works or fails as we expect.  We
are
also afforded a configurable timeout \0/. It's currently set to 360 minutes
for the overcloud upgrade jobs.

2. Once this is proven out, we can run upgrade jobs as third party on any
review upstream

3. New coverage should be prototyped in RDO Software Factory

4. If jobs prove to be reliable and consistent and run under 170 minutes we
move what
we can back upstream.

WDYT?


>
> 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
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170928/879f852d/attachment.html>