Open Stack

On Fri, Aug 5, 2016 at 1:58 PM, Steven Hardy <shardy at redhat.com> 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.

ok, /me working on 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).

ack

>> 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.

Yes, my final goal was to have a job like:
1) deploy Mitaka undercloud
2) deploy Mitaka overcloud
3) run pingtest
4) upgrade undercloud to Newton
5) upgrade overcloud to newton
6) re-run pingtest



-- 
Emilien Macchi