Re: [openstack-dev] [tripleo] tripleo-upgrade pike branch

[Marius Cornea]

On Fri, Jan 19, 2018 at 4:47 PM, John Trowbridge  wrote:
>
>
> On Fri, Jan 19, 2018 at 10:21 AM, Wesley Hayutin 
> wrote:
>>
>> Thanks Marius for sending this out and kicking off a conversation.
>>
>> On Tue, Jan 2, 2018 at 12:56 PM, Marius Cornea  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
time.

> 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 [1].
>> I think we need to see some external and internal
>> jobs checking and gating this role with comments posted to changes.
>>
>> [1]
>> https://review.rdoproject.org/jenkins/job/gate-tripleo-ci-centos-7-containers-multinode-upgrades-pike/
>>
>>
>>>
>>>
>>> I wanted to bring this topic up for discussion to see if branching is
>>> the proper thing to do here.
>>>
>>> Thanks,
>>> Marius
>>>
>>>
>>> __
>>> 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
>>
>>
>
>
> __
> 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
>

__
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

Re: [openstack-dev] [tripleo] tripleo-upgrade pike branch

[Marius Cornea]

On Fri, Jan 19, 2018 at 4:21 PM, Wesley Hayutin  wrote:
> Thanks Marius for sending this out and kicking off a conversation.
>
> On Tue, Jan 2, 2018 at 12:56 PM, Marius Cornea  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 think it would probably be the same when using multiple release
conditionals, we'd still have to trigger one job/release if we wanted
full coverage.

> 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 [1].
> I think we need to see some external and internal
> jobs checking and gating this role with comments posted to changes.
>
> [1]
> https://review.rdoproject.org/jenkins/job/gate-tripleo-ci-centos-7-containers-multinode-upgrades-pike/
>
>
>>
>>
>> I wanted to bring this topic up for discussion to see if branching is
>> the proper thing to do here.
>>
>> Thanks,
>> Marius
>>
>> __
>> 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
>
>
>
> __
> 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
>

__
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

Re: [openstack-dev] [tripleo] tripleo-upgrade pike branch

[John Trowbridge]

On Fri, Jan 19, 2018 at 10:21 AM, Wesley Hayutin 
wrote:

> Thanks Marius for sending this out and kicking off a conversation.
>
> On Tue, Jan 2, 2018 at 12:56 PM, Marius Cornea  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.

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 [1].
>  I think we need to see some external and internal
> jobs checking and gating this role with comments posted to changes.
>
> [1] https://review.rdoproject.org/jenkins/job/gate-tripleo-
> ci-centos-7-containers-multinode-upgrades-pike/
>
>
>
>>
>> I wanted to bring this topic up for discussion to see if branching is
>> the proper thing to do here.
>>
>> Thanks,
>> Marius
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
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

Re: [openstack-dev] [tripleo] tripleo-upgrade pike branch

[Wesley Hayutin]

Thanks Marius for sending this out and kicking off a conversation.

On Tue, Jan 2, 2018 at 12:56 PM, Marius Cornea  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.

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 [1].
 I think we need to see some external and internal
jobs checking and gating this role with comments posted to changes.

[1]
https://review.rdoproject.org/jenkins/job/gate-tripleo-ci-centos-7-containers-multinode-upgrades-pike/



>
> I wanted to bring this topic up for discussion to see if branching is
> the proper thing to do here.
>
> Thanks,
> Marius
>
> __
> 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
>
__
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

[openstack-dev] [tripleo] tripleo-upgrade pike branch

[Marius Cornea]

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 wanted to bring this topic up for discussion to see if branching is
the proper thing to do here.

Thanks,
Marius

__
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