<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 9, 2021 at 6:46 PM Jesse Pretorius <<a href="mailto:jesse@odyssey4.me">jesse@odyssey4.me</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div style="overflow-wrap: break-word;">
<br>
<div><br>
<blockquote type="cite">
<div>On 9 Feb 2021, at 16:29, Wesley Hayutin <<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>> wrote:</div>
<br>
<div>
<div dir="ltr">
<div><b>Upgrade jobs in master:</b></div>
<div>All the upgrade jobs in master are non-voting based on policy and to give the upgrade developers time to compensate for new developments and features.   The feedback provided by CI can still occur in our periodic jobs in RDO's software factory
 zuul.   Upgrade jobs will remain running in periodic but removed from upstream.</div>
<div><br>
</div>
<div>Specifically:  ( master ) </div>
<div>tripleo-ci-centos-8-standalone-upgrade<br>
tripleo-ci-centos-8-undercloud-upgrade<br>
tripleo-ci-centos-8-scenario000-multinode-oooq-container-upgrades<br>
</div>
<div><br>
</div>
<div>I'll note there is interest in keeping the undercloud-upgrade, however we are able to remove all the upgrade jobs for a branch in the upstream we can also remove a content-provider job.  I would encourage folks to consider undercloud-upgrade for
 periodic only.  </div>
</div>
</div>
</blockquote>
<br>
</div>
<div>+1 I think this makes sense. These jobs are long running and consume quite a few VM over that lengthy period of time.</div>
<br></div></blockquote><div><br></div><div><br></div><div>just to be clear however, note that this means that there will be no stable/wallaby version of these upgrades jobs, or at least it will be a lot harder to add them if we aren't running these jobs against master. In the 'normal' case, the non-voting master jobs become the voting stable/latest once we have created the new latest branch. If we remove master we may have a challenge to add voting stable/wallaby versions when the time comes. </div><div><br></div><div>Based on our recent discussions, we don't *want* stable/wallaby versions since we want to eventually remove all the upstream upgrade jobs once d/stream replacements have been put in place. </div><div><br></div><div>The point then is that ideally we need to be in a position to do that (i.e. replacement jobs in place) before stable/wallaby is branched, otherwise we may have a tough time adding stable/wallaby versions of the (removed) master upgrade jobs.</div><div><br></div><div>regards, marios<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div></div></div>