<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 19, 2018 at 10:21 AM, Wesley Hayutin <span dir="ltr"><<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Marius for sending this out and kicking off a conversation.<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Jan 2, 2018 at 12:56 PM, Marius Cornea <span dir="ltr"><<a href="mailto:mariusc@redhat.com" target="_blank">mariusc@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi everyone and Happy New Year!<br>
<br>
As the migration of tripleo-upgrade repo to the openstack namespace is<br>
now complete I think it's the time to create a Pike branch to capture<br>
the current state so we can use it for Pike testing and keep the<br>
master branch for Queens changes. The update/upgrade steps are<br>
changing between versions and the aim of branching the repo is to keep<br>
the update/upgrade steps clean per branch to avoid using conditionals<br>
based on release. Also tripleo-upgrade should be compatible with<br>
different tools used for deployment(tripleo-quickstart, infrared,<br>
manual deployments) which use different vars for the version release<br>
so in case of using conditionals we would need extra steps to<br>
normalize these variables.<br></blockquote><div><br></div></span><div>I understand the desire to create a branch to protect the work that has been done previously.</div><div>The interesting thing is that you guys are proposing to use a branched ansible role with</div><div>a branchless upstream project. I want to make sure we have enough review so that we don't hit issues </div><div>in the future. Maybe that is OK, but I have at least one concern.</div><div><br></div><div>My conern is about gating the tripleo-upgrade role and it's branches. When tripleo-quickstart is changed</div><div>which is branchless we will be have to kick off a job for each tripleo-upgrade branch? That immediately doubles</div><div>the load on gates.</div></div></div></div></blockquote><div><br></div><div>I do not think CI repos should be branched. Even more than the concern Wes brought up about a larger gate matrix. Think</div><div>about how much would need to get backported. To start you would just have the 2 branches, but eventually you will have 3.</div><div>Likely all 3 will have slight differences in how different pieces of the upgrade are called (otherwise why branch), so when</div><div>you need to fix something on all branches the backports have a high potential to be non-trivial too.</div><div><br></div><div>Release conditionals are not perfect, but I dont think compatibility is really a major issue. Just document how to set the</div><div>release, and the different CI tools that use your role will just have to adapt to that.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>It's extemely important to properly gate this role against the versions of TripleO and OSP. I see very limited</div><div>check jobs and gate jobs on tripleo-upgrades atm. I have only found [1]. I think we need to see some external and internal</div><div>jobs checking and gating this role with comments posted to changes.</div><div><br></div><div>[1] <a href="https://review.rdoproject.org/jenkins/job/gate-tripleo-ci-centos-7-containers-multinode-upgrades-pike/" target="_blank">https://review.rdoproject.<wbr>org/jenkins/job/gate-tripleo-<wbr>ci-centos-7-containers-<wbr>multinode-upgrades-pike/</a></div><span class=""><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I wanted to bring this topic up for discussion to see if branching is<br>
the proper thing to do here.<br>
<br>
Thanks,<br>
Marius<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>