Open Stack

On 01/26/2017 10:00 AM, Emilien Macchi wrote:
> 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.
> 

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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
>