Open Stack

On 08/05/2016 12:58 PM, Steven Hardy wrote:
> On Thu, Aug 04, 2016 at 09:46:20PM -0400, Emilien Macchi wrote:
>> Hi,
>>
>> I'm currently working by iteration to get a new upstream job that test
>> upgrades and update.
>> Until now, I'm doing baby steps. I bootstrapped the work to upgrade
>> undercloud, see https> ://review.openstack.org/#/c/346995/ for details
>> (it's almost working hitting a packaging issue now).
>>
>> Now I am interested by having 2 overcloud jobs:
>>
>> - update: Newton -> Newton: basically, we already have it with
>> gate-tripleo-ci-centos-7-ovb-upgrades - but my proposal is to use
>> multinode work that James started.
>> I have a PoC (2 lines of code):
>> https://review.openstack.org/#/c/351330/1 that works, it deploys an
>> overcloud using packaging, applies the patch in THT and run overcloud
>> update. I tested it and it works fine, (I tried to break Keystone).
>> Right now the job name is
>> gate-tripleo-ci-centos-7-nonha-multinode-upgrades-nv because I took
>> example from the existing ovb job that does the exact same thing.
>> I propose to rename it to
>> gate-tripleo-ci-centos-7-nonha-multinode-updates-nv. What do you
>> think?
> 
> This sounds good, and it seems to be a valid replacement for the old
> "upgrades" job - it won't catch all kinds of update bugs (in particular it
> obviously won't run any packaged based updates at all), but it will catch
> the most serious template regressions, which will be useful coverage to
> maintain I think.
> 
>> - upgrade: Mitaka -> Newton: I haven't started anything yet but the
>> idea is to test the upgrade from stable to master, using multinode job
>> now (not ovb).
>> I can prototype something but I would like to hear from our community before.
> 
> I think getting this coverage in place is very important, we're
> experiencing a lot of post-release pain due to the lack of this coverage,
> so +1 on any steps we can take to get some coverage here, I'd say go ahead
> and do the prototype if you have time to do it.
> 
> You may want to chat with weshay, as I know there are some RDO upgrade
> tests which were planned to be run as third-party jobs to get some upgrade
> coverage - I'm not sure if there is any scope for reuse here, or if it will
> be easier to just wire in the upgrade via our current scripts (obviously
> some form of reuse would be good if possible).
> 
>> Please give some feedback if you are interested by this work and I
>> will spend some time during the next weeks on $topic.
>>
>> Note: please also look my thread about undercloud upgrade job, I need
>> your feedback too.
> 
> My only question about undercloud upgrades is whether we might combine the
> overcloud upgrade job with this, e.g upgrade undercloud, then updgrade
> overcloud.  Probably the blocker here will be the gate timeout I guess,
> even if we're using pre-cached images etc.

Yeah, we'd probably have to cut a bunch of runtime off somewhere.  Just
the undercloud upgrade alone starting from a pre-built Mitaka image
(which we might be able to do in CI, but it would be a little tricky and
I'm not positive it would work) was taking 20-25 minutes when I was
running it a while ago.  It's probably even slower now.  Add that to the
already long time the overcloud part takes and I don't see how it would
fit in under the timeout.

This is why I was running a job locally instead of adding it to
tripleo-ci (with the intent that some day I would figure out how to move
it into upstream infra like Emilien did :-).

> 
> Thanks for looking into this!
> 
> 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
>