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