On 01/26/2017 10:00 AM, Emilien Macchi wrote: > On Thu, Jan 26, 2017 at 9:51 AM, John Trowbridge <[email protected]> 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. >
I think this approach is great and should allow transitioning it to run via quickstart to be simple after we have the scenario jobs in quickstart. >> 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: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
