[lustre-devel] [LSF/MM/BPF TOPIC] [DRAFT] Lustre client upstreaming

[Alexey Lyahkov]

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.
In previous iteration - Ubuntu had an build a kernels with lustre support enabled.
But Ubuntu don’t have a resources to fix own kernel with lustre back ports.
these clients have installed and some clients expect to be work fine.
But this is false, and building an new lustre module have a conflict in names between kernel and out-of tree lustre.
From other side - it make a Lustre platform fragmentation. Once Lustre version in the Ubuntu code have a stale and out generic lustre rule.
Compatibility supported just for one version up and down. It caused a so much problems for support team.

And Ubuntu just one distro. RedHat, SuSe, LTS kernels… all of them used in HPC - all of then have an own release cycle and so much versions had hold a some lustre version to use.


Alex