Open Stack

On Thu, Jan 26, 2017 at 9:51 AM, John Trowbridge <trown at redhat.com> wrote:
>
>
> On 01/26/2017 04:03 AM, mathieu bultel wrote:
>> Hi,
>>
>> I'm sending this email to the list to request reviews about the
>> composable upgrade work I have been done in Tripleo quickstart. It's
>> pending for a while (dec 4 for one of those 2 reviews), and I have
>> addressed all the comments on time, rebase & so one [1].
>> Those reviews is required, and very important for 3 reasons:
>> 1/ It addressed the following BP: [2]
>> 2/ It would give a tool for the other Squad and DFGs to start to play
>> with composable upgrade in order to support their own components.
>> 3/ It will be a first shot for the Tripleo-CI / Tripleo-Quickstart
>> transition for supporting the tripleo-ci upgrade jobs that we have
>> implemented few weeks ago now.
>>
>> I updated the documentation (README) regarding the upgrade workflow, the
>> commit message explain the deployment workflow, I know it's not easy to
>> review this stuff, and probably tripleo-quickstart cores don't give
>> importance around this subject. I think I can't do much more now for
>> making the review more easy for the Cores.
>>
>> It was one of my concerns about adding all the very specific extras
>> roles (upgrade / baremetal / scale) in one common repo, loosing flexibly
>> and reaction, but it's more than that...
>>
>> I'm planning to write a "How To" for helping to other DFGs/Squads to
>> work on upgrade, but since this work is still under review, I'm stuck.
>>
>> Thanks.
>>
>> [1]
>> tripleo-quickstart repo:
>> https://review.openstack.org/#/c/410831/
>> tripleo-quickstart-extras repo:
>> https://review.openstack.org/#/c/416480/
>>
>> [2]
>>
>> https://blueprints.launchpad.net/tripleo/+spec/tripleo-composable-upgrade-job
>>
>
> We discussed this a bit this morning on #tripleo, and the consensus
> there was that we should be focusing upgrade CI efforts for the end of
> Ocata cycle on the existing tripleo-ci multinode upgrades job. This is
> due to priority constraints on both sides.
>
> On the quickstart side, we really need to focus on having good
> replacements for all of the basic jobs which are solid (OVB, multinode,
> scenarios), so we can switch over in early Pike.
>
> On the upgrades side, we really need to focus on having coverage for as
> many services to upgrade as possible.

I'm currently working on this front, by implementing the
scenarioXXX-upgrade jobs (with multinode, but not oooq yet):
https://review.openstack.org/#/c/425727/

Any feedback on the review is welcome, I hope it's aligned with our plans.

> As such, I think we should use the existing job for upgrades, and port
> it to quickstart after we have switched over the basic jobs in early Pike.
>
> One note about making it easier to get patches reviewed. As a group, I
> think we have been reviewing quickstart/extras patches at a very good
> pace. However, adding a very large feature with no CI covering it, makes
> me personally totally uninterested to review. Not only does it require
> me to follow some manual instructions just to see it actually works, but
> there is nothing preventing it from being completely broken within days
> of merging the feature.
>
> Another thing we should probably document for Tripleo CI somewhere is
> that we should be trying to create multinode based CI for anything that
> does not require nova/ironic interactions. Upgrades are in this category.
>
> __________________________________________________________________________
> 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



-- 
Emilien Macchi