[openstack-dev] [tripleo] scenario000-multinode-oooq-container-upgrades

Wesley Hayutin whayutin at redhat.com
Tue Jun 12 16:29:55 UTC 2018


On Tue, Jun 12, 2018 at 11:21 AM James Slagle <james.slagle at gmail.com>
wrote:

> On Tue, Jun 12, 2018 at 11:03 AM, Jiří Stránský <jistr at redhat.com> wrote:
> > On 12.6.2018 15:06, James Slagle wrote:
> >>
> >> On Mon, Jun 11, 2018 at 3:34 PM, Wesley Hayutin <whayutin at redhat.com>
> >> wrote:
> >>>
> >>> Greetings,
> >>>
> >>> I wanted to let everyone know that we have a keystone only deployment
> and
> >>> upgrade job in check non-voting.  I'm asking everyone in TripleO to be
> >>> mindful of this job and to help make sure it continues to pass as we
> move
> >>> it
> >>> from non-voting check to check and eventually gating.
> >>
> >>
> >> +1, nice work!
> >>
> >>> Upgrade jobs are particularly difficult to keep running successfully
> >>> because
> >>> of the complex workflow itself, job run times and other factors.  Your
> >>> help
> >>> to ensure we don't merge w/o a pass on this job will go a long way in
> >>> helping the tripleo upgrades team.
> >>>
> >>> There is still work to be done here, however it's much easier to do it
> >>> with
> >>> the check non-voting job in place.
> >>
> >>
> >> The job doesn't appear to be passing at all on stable/queens. I see
> >> this same failure on several patches:
> >>
> >>
> http://logs.openstack.org/59/571459/1/check/tripleo-ci-centos-7-scenario000-multinode-oooq-container-upgrades/8bbd827/logs/undercloud/home/zuul/overcloud_upgrade_run_Controller.log.txt.gz
> >>
> >> Is this a known issue?
> >
> >
> > I think so, or to put it precisely, i only ever looked into making the
> job
> > work for master (and beyond).
> >
> > We could look into making it work on Queens too, but personally i think
> > effort would be better spent elsewhere at this point. E.g. upd+upg jobs
> with
> > more complete of services utilizing containerized undercloud (those would
> > not validate OC workflow at all, but would give coverage for
> > update_tasks/upgrade_tasks), user and dev docs around all lifecycle ops
> > (upd, upg, ffwd), upgrade work in the area of TLS by default, upgrade
> > handling for external_deploy_tasks (= "how do we upgrade Ceph in Rocky"),
> > also perhaps trying to DRY repeated parts of upgrade templates, etc.
> >
> > If someone wants to step up to iron out Queens issues with that job then
> we
> > can do it, but my 2 cents would be just to disable the job on Queens and
> > focus on the future.
>
> Sure, I'm just trying to figure out what can safely be ignored. The
> tone of the original email was encouraging reviewers not to ignore the
> job. Let's remove it from queens then, as right now it's just noise.
>

I think we missed a patch [1] to correctly set the release for the job.
I'll take a look at the results.

I may have jumped the gun w/ the tone of the email w/ regards to keeping it
running.  I'll make the adjustment on queens for now [2].

Thanks for catching that James, Jirka!

[1] https://review.openstack.org/#/c/574417/
[2] https://review.openstack.org/574794


>
>
>
> --
> -- James Slagle
> --
>
> __________________________________________________________________________
> 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/20180612/515b51b2/attachment.html>


More information about the OpenStack-dev mailing list