[lustre-devel] [LSF/MM/BPF TOPIC] [DRAFT] Lustre client upstreaming
NeilBrown
neilb at suse.de
Wed Jan 22 12:54:11 PST 2025
On Mon, 20 Jan 2025, Alexey Lyahkov wrote:
>
> > On 19 Jan 2025, at 11:03, NeilBrown <neilb at suse.de> wrote:
> >
> > On Sun, 19 Jan 2025, Alexey Lyahkov wrote:
> >> Neil,
> >>>
> >>>
> >>>>
> >>>> It does not hep that there are what 3? 4? trees, not "dual-tree" by any
> >>>> stretch of imagination.
> >>>>
> >>>> There's DDN/whamcloud (that's really two trees), there's HPE, LLNL
> >>>> keeps their fork still I think (thought it's mostly backports?). There
> >>>> are likely others I am less exposed to.
> >>>
> >>> "dual-tree" maybe isn't the best way of describing what was wrong with
> >>> the previous approach. "upstream-first" is one way of describing how it
> >>> should be run, though that needs to be in understood correctly.
> >>>
> >>> Patches should always flow upstream first, then flow downstream into
> >>> distro. So I write a patch in my own devel tree. I post it or submit a
> >>> pull request and eventually it is accepted into the maintainers
> >>> "testing" tree (upsream from me). There it gets more testing and moves
> >>> to the maintainers "next" tree from which it is pulled into linux-next
> >>> for integration testing. Then it goes upstream to Linus (possibly
> >>> through an intermediary). From Linus it goes to -stable and to various
> >>> distros etc. Individual patches are selected for further backporting to
> >>> all sorts of different LTS tree.
> >>>
> >>> Occasionally there are short-cuts. I might submit a patch from my tree
> >>> to a SUSE kernel before it is accepted upstream, or maybe even before it
> >>> is sent if it is urgent. But these are not the norm.
> >>>
> >>> But you know all this I expect. It isn't about the total number of
> >>> trees. It is about the flow of patches which must all flow through Linus.
> >>> And developers must develop against current linus, or something very
> >>> close to that. Developing against an older kernel is simply making more
> >>> work for yourself.
> >>
> >> This will don’t work. Let explain situation in past.
> >
> > No. I'm not at all interested in explanations of why it won't work.
> >
> > I'm only interested in suggestions of how to make it work, and offers of
> > help.
> >
> If you have a good way how to solve such situation, which had crazy brain in past.
> Please share a way how to avoid lustre source code fragmentation because of freeze a code at the different stage in different distributions.
> Ubuntu might have a modern lustre with 6.5 kernel, but Redhat had frozen a lustre version in 3 releases in past and these clients not compatible each other.
> And not compatible with installed server.
> So question - who will do such support ? Did you have an ideas how to solve this problem?
>
sorry - I didn't mean to go quite on you - I've been busy :-)
It's not entirely clear to me what the problem is.
You talk about clients not being compatible with each other or with the
server, but Andreas has said that there is good compatibility between
different versions so I wonder if that is really (still) an issue.
Keeping different kernels up to date with new updates is something that
the linux-stable team does all the time. We do it at SUSE to. It isn't
that hard.
You identify which patches *need* to be backported (ideally when the
patch is created but that isn't always easy) and you use tools to help
you backport them.
Certainly there is effort involved, but maintaining a package that works
on a large set of kernels also involves effort. It isn't clear to me
that it is *more* effort, just *different* effort.
NeilBrown
More information about the lustre-devel
mailing list