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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev