On Tue, Jun 12, 2018 at 11:21 AM James Slagle <james.sla...@gmail.com>
> On Tue, Jun 12, 2018 at 11:03 AM, Jiří Stránský <ji...@redhat.com> wrote:
> > On 12.6.2018 15:06, James Slagle wrote:
> >> On Mon, Jun 11, 2018 at 3:34 PM, Wesley Hayutin <whayu...@redhat.com>
> >> wrote:
> >>> Greetings,
> >>> I wanted to let everyone know that we have a keystone only deployment
> >>> 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
> >>> 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:
> >> Is this a known issue?
> > I think so, or to put it precisely, i only ever looked into making the
> > 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
> > 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
> > 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  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 .
Thanks for catching that James, Jirka!
> -- James Slagle
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)