On Thu, Jan 26, 2017 at 9:51 AM, John Trowbridge <tr...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Emilien Macchi __________________________________________________________________________ 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