Open Stack

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.

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.