Open Stack

On Wed, Nov 2, 2022 at 3:04 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:

> Hi Jay,
>
> On Tue, Nov 1, 2022 at 8:17 PM Jay Faulkner <jay at gr-oss.io> wrote:
>
>> Hey all,
>>
>> I've been looking into the various zuul config errors showing up for
>> Ironic-program branches. Almost all of our old bugfix branches are in the
>> list. Additionally, not properly retiring the bugfix branches leads to an
>> ever-growing list of branches which makes it a lot more difficult, for
>> contributors and operators alike, to tell which ones are currently
>> supported.
>>
>
> I'd like to see the errors. We update Zuul configuration manually for each
> bugfix branch, mapping appropriate branches for other projects (devstack,
> nova, etc). It's possible that we always overlook a few jobs, which causes
> Zuul to be upset (but quietly upset, so we don't notice).
>
>

The errors show up in https://zuul.opendev.org/t/openstack/config-errors --
although they seem to be broken this morning. Most of them are older bugfix
branches, ones that are out of support, that have the `Queue: Ironic` param
that's no longer supported. I am not in favor of anyone going to dead
bugfix branches and fixing CI; instead we should retire the ones out of use.


>
>> I've put together a document describing the situation as it is now, and
>> my proposal:
>> https://etherpad.opendev.org/p/IronicBugfixBranchCleanup
>>
>
> Going with the "I would like to retire" would cause us so much trouble
> that we'll have to urgently create a downstream mirror of them. Once we do
> this, using upstream bugfix branches at all will be questionable.
> Especially bugfix/19.0 (and corresponding IPA/inspector branches) is used
> in a very actively maintained release.
>
>

Then we won't; but we do need to think about what timeline we can talk
about upstream for getting a cadence for getting these retired out, just
like we have a cadence for getting them cut every two months. I'll revise
the list and remove the "I would like to retire" section (move it to
keep-em-up).


>
>> Essentially, I think we need to:
>> - identify bugfix branches to cleanup (I've done this in the above
>> etherpad, but some of the )
>> - clean them up (the next step)
>> - update Ironic policy to set a regular cadence for when to retire bugfix
>> branches, and encode the process for doing so
>>
>> This means there are two overall questions to answer in this email:
>> 1) Mechanically, what's the process for doing this? I don't believe the
>> existing release tooling will be useful for this, but I'm not 100% sure.
>> I've pulled (in the above etherpad and a local spreadsheet) the last SHA
>> for each branch; so we should be able to EOL these branches similarly to
>> how we EOL stable branches; except manually instead of with tooling. Who is
>> going to do this work? (I'd prefer releases team continue to hold the keys
>> to do this; but I understand if you don't want to take on this manual work).
>>
>
> EOL tags will be created by the release team, yes. I don't think we can
> get the keys without going "independent".
>
>

It's a gerrit ACL you can enable to give other people access to tags; but
like I said, I don't want that access anyway :).


>
>> 2) What's the pattern for Ironic to adopt regarding these branches? We
>> just need to write down the expected lifecycle and enforce it -- so we
>> prevent being this deep into "branch debt" in the future.
>>
>
> With my vendor's (red) hat on, I'd prefer to have a dual approach: the
> newest branches are supported by the community (i.e. us all), the oldest -
> by vendors who need them (EOLed if nobody volunteers). I think you already
> have a list of branches that OCP uses? Feel free to point Riccardo, Iury or
> myself at any issues with them.
>
>
That's not really an option IMO. These branches exist in the upstream
community, and are seen by upstream contributors and operators. If they're
going to live here; they need to have some reasonable documentation about
what folks should expect out of them and efforts being put towards them.
Even if the documentation is "bugfix/1.2 is maintained as long as Product A
1.2 is maintained", that's better than leaving the community guessing about
what these are used for, and why some are more-supported than others.

-Jay


Dmitry
>
>
>>
>>
>> What do folks think?
>>
>> -
>> Jay Faulkner
>>
>
>
> --
>
> Red Hat GmbH <https://www.redhat.com/de/global/dach>, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany
> Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20221102/65fe6c38/attachment.htm>