Open Stack

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.

Jirka