[Lustre-discuss] 1.6.5.1 patches

[Brian J. Murrell]

On Fri, 2008-10-10 at 22:12 +0200, Papp Tamás wrote:
> hi All,

Hi,

> What patches should be applied for 1.6.5.1 to get it more stable (also 
> the same question for patchless clients)?

Well, by definition, all of the patches that will be applied to release
n are needed by release n-1.  For 1.6.5.1 that would be all of the
patches we have scheduled to land for 1.6.6.

That may sound like a silly answer, but that really is the truth.

It's not quite that simple however.  Until a release (let's call it
1.6.6 for example) has gone through our QA process, there is no
assurance that there are not inter-patch defects (more commonly referred
to as ripple effects).  Otherwise we could just apply a patch and make
1.6.5.2 and apply another and call it 1.6.5.3, etc.

> I've found this in a bugzilla comment for clients:
> 
> https://bugzilla.lustre.org/attachment.cgi?id=18103&action=edit

Yes, that one can be an important one.

> And this at the list:
> 
> https://bugzilla.lustre.org/show_bug.cgi?id=16496

Not sure how important this one is, but as I will get to, it's all
relative.

> What else patches are proposed to use?

We had recently advised one customer recently to apply the following
attachments:

attachment 18121
attachment 18293
attachment 19123
attachment 18103

In addition to a few others that were to fix problems particular to
their installation.

But this is the rub.  Which patches any site should apply to a release
depends on what their use patterns are like and which bugs they are
running into as a result.

Given the warning above about ripple effects, applying patches to a
given release is a careful balance between minimizing risks of ripple
effects and getting the fixes for the particular problems that are
ailing you.  Obviously the more testing you can do of your release
+patches build before going live, the more patches you should be able to
sustain without rude go-live incidents.

> Is there any chance in the future to make these patches collected 
> somehow (for example more frequently source-only mini release , like 
> 1.6.5.x, or a website, or something like that)?

As for more frequent releases, the problem we have with that is that our
QA process is quite involved due to the complexity of Lustre and the
array of kernels and architectures we have to test on to call any given
release "fully QA certified".  As can be witnessed by 1.6.5.1 (and the
few 1.6.4.x releases) however, occasionally the need is justified.

As for a website, I suppose you are looking for an enumeration of
patches that will be applied to release n to get n+1.  You can get
information that from our bugzilla in the form of the release tracking
bugs.

For any given release there is a bug tracking all of the bugs that will
be applied to release n-1 to get release n.  We usually give those
tracking bugs an alias of the form wxy[z]-tracking where w, x, y and
possible z are the digits from the release.  So for 1.6.6 you'd be
interested in "166-tracking" which you can put into a "bug number" field
in our BZ and you will get bug 14883.  All of the bugs in the Depends
on: field are the bugs with patches that have gone into 1.6.5 to get
1.6.6.

If you wanted to be notified when a new bug has been identified as
needing to go into a release you could simply subscribe yourself to the
release tracker and you will get notified of updates to that Depends on:
field.

Hopefully this tells you all you need to know (and more) about our
release process.