[tripleo][ci] socializing upstream job removal ( master upgrade, scenario010 )

Marios Andreou marios at redhat.com
Wed Feb 10 06:39:42 UTC 2021

On Tue, Feb 9, 2021 at 7:19 PM Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2021-02-09 19:03:58 +0200 (+0200), Marios Andreou wrote:
> [...]
> > 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.
> >
> > 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.
> >
> > 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.
> If for some reason you aren't able to get that far in Wallaby,
> running this once a day in the periodic pipeline in OpenDev's Zuul
> would still be *far* less resource-intensive than the current state
> of running multiple times for most proposed changes, and so could
> serve as a reasonable compromise.

ack thanks and yeah we are definitely keeping our 3rd party periodics on
these but good point we could also consider the upstream periodic i almost
forgot we have one of those defined  too ;)

regards, marios

> --
> Jeremy Stanley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210210/e5e71d7c/attachment.html>

More information about the openstack-discuss mailing list