[nova] Backporting test refactors to stable/train

Artom Lifshitz alifshit at redhat.com
Tue Sep 14 20:06:15 UTC 2021

On Tue., Sep. 14, 2021, 15:57 Lee Yarwood, <lyarwood at redhat.com> wrote:

> On 14-09-21 13:55:14, Artom Lifshitz wrote:
> > Hey Elod and Vlad (and the ML, cc'ed)
> >
> > This is continuing the conversation Elod and I had on IRC. The
> > immediate context is [1], which is a test refactor backport that in
> > turn enables conflict-free backporting of at least two fixes.
> >
> > From Red Hat's point of view, we will have to care about stable/train
> > for *very* long time, so we'd like to do everything we can to make our
> > lives easier, including backportings things are aren't strictly
> > necessary (like test refactors) in order to greatly facilitate future
> > backports, which tend to be of the "func reproducer test + actual fix"
> > variety.
> >
> > Elod made the excellent point that while this approach does make
> > backports to train much easier to both write and review, it also
> > "postpones" all of the manual conflict resolution work onto anyone
> > doing stable/stein backports.
> I can't say I agree with the objection here but regardless I think the
> ship has already sailed on us backporting many of these test refactors to
> stable/train.

Maybe, but at least in some cases it's still possible, like my [1] link in
my previous message.

We have already backported so by manually resolving conflicts and that
> would now conflict again with any attempt to backport the refactors. At
> least that has been my experience the last few times I tried to do this
> and I've now given up and manually resolved conflicts, for example:
> https://review.opendev.org/c/openstack/nova/+/785847
> Going forward however and with my dusty old Red Hat on I want to try to
> do this as much as possible back to stable/wallaby to allow fixes to
> flow through our stable branches as seamlessly as possible.
> I don't see why such contributions should be blocked, the work required
> to resolve these conflicts would eventually have to be done by someone,
> pushing that to contributors who care about a given older release only
> seems fair IMHO.

Fair, hard to argue with "if you care about something, put in the work."

> I went and gathered data. I looked at the last 6 months of backports
> > in Gerrit. At the time of this writing, stable/train 72 [2] had and
> > stable/stein had 24 [3]. Out of the latter, Vlad Gusev was the main
> > non-Red Hat contributor.
> Slight tangent but only 20 landing for train and 10 landing for stein.
> If anyone is interested in becoming a stable core on Nova please feel
> free to reach out as we could really use more reviewers.
> > So my proposal is simple: I'm willing to help resolve conflicts in
> > stable/stein backport for folks like Vlad, if it means making
> > backports to stable/train easier. I'm confident that it would still
> > mean an overall reduction in man-hours for backports, even if I become
> > personally on the hook to deal with the fallout of backporting test
> > refactors to stable/train.
> Well that's good of you Artom but I don't think that should be required
> to land such backports on a given stable branch.

Just trying to be a good community citizen, and show that I'm open to
listen to others' concerns :) (And, full disclosure, also making the bet
that it'll happen so rarely that it won't affect me.)

> Cheers,
> Lee
> > [1] https://review.opendev.org/c/openstack/nova/+/791481
> > [2]
> https://review.opendev.org/q/project:openstack/nova+branch:stable/train+-age:6month
> > [3]
> https://review.opendev.org/q/project:openstack/nova+branch:stable/stein+-age:6month
> --
> Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672
> 2D76
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210914/d06921c5/attachment-0001.htm>

More information about the openstack-discuss mailing list