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

> On 19 Jan 2025, at 11:03, NeilBrown <[email protected]> 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?


> And yes - describing important use-cases which need to work and might be
> difficult would be a helpful thing to do.
> 
> NeilBrown
> 


> 
>> 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
> 

_______________________________________________
lustre-devel mailing list
[email protected]
http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org