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

James Slagle james.slagle at gmail.com
Tue Jun 12 15:20:51 UTC 2018


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.



-- 
-- James Slagle
--



More information about the OpenStack-dev mailing list