[openstack-dev] [tripleo] tripleo-upgrade pike branch
mariusc at redhat.com
Mon Jan 22 13:48:31 UTC 2018
On Fri, Jan 19, 2018 at 4:47 PM, John Trowbridge <trown at redhat.com> wrote:
> On Fri, Jan 19, 2018 at 10:21 AM, Wesley Hayutin <whayutin at redhat.com>
>> Thanks Marius for sending this out and kicking off a conversation.
>> On Tue, Jan 2, 2018 at 12:56 PM, Marius Cornea <mariusc at redhat.com> wrote:
>>> Hi everyone and Happy New Year!
>>> As the migration of tripleo-upgrade repo to the openstack namespace is
>>> now complete I think it's the time to create a Pike branch to capture
>>> the current state so we can use it for Pike testing and keep the
>>> master branch for Queens changes. The update/upgrade steps are
>>> changing between versions and the aim of branching the repo is to keep
>>> the update/upgrade steps clean per branch to avoid using conditionals
>>> based on release. Also tripleo-upgrade should be compatible with
>>> different tools used for deployment(tripleo-quickstart, infrared,
>>> manual deployments) which use different vars for the version release
>>> so in case of using conditionals we would need extra steps to
>>> normalize these variables.
>> I understand the desire to create a branch to protect the work that has
>> been done previously.
>> The interesting thing is that you guys are proposing to use a branched
>> ansible role with
>> a branchless upstream project. I want to make sure we have enough review
>> so that we don't hit issues
>> in the future. Maybe that is OK, but I have at least one concern.
>> My conern is about gating the tripleo-upgrade role and it's branches.
>> When tripleo-quickstart is changed
>> which is branchless we will be have to kick off a job for each
>> tripleo-upgrade branch? That immediately doubles
>> the load on gates.
> I do not think CI repos should be branched. Even more than the concern Wes
> brought up about a larger gate matrix. Think
> about how much would need to get backported. To start you would just have
> the 2 branches, but eventually you will have 3.
> Likely all 3 will have slight differences in how different pieces of the
> upgrade are called (otherwise why branch), so when
> you need to fix something on all branches the backports have a high
> potential to be non-trivial too.
Once we release we expect the upgrade/update process to be stable and
no changes required to the process so I expect the backports to be
minimal, mostly for scenarios that we missed in testing at release
> Release conditionals are not perfect, but I dont think compatibility is
> really a major issue. Just document how to set the
> release, and the different CI tools that use your role will just have to
> adapt to that.
>> It's extemely important to properly gate this role against the versions of
>> TripleO and OSP. I see very limited
>> check jobs and gate jobs on tripleo-upgrades atm. I have only found .
>> I think we need to see some external and internal
>> jobs checking and gating this role with comments posted to changes.
>>> I wanted to bring this topic up for discussion to see if branching is
>>> the proper thing to do here.
>>> OpenStack Development Mailing List (not for usage questions)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev