<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-text-html" lang="x-western">
<div class="moz-cite-prefix">I find this entire thread to be huge
gentlemen.<br>
It has everything to do with my nubie status with FAI plus end
user community.<br>
<br>
<br>
On 03/12/2013 06:36 AM, Thomas Lange wrote:<br>
</div>
<blockquote
cite="mid:20799.1321.199634.564580@hellers.informatik.uni-Koeln.de"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">On Tue, 12 Mar 2013 11:26:45 +0100, Dirk Geschke <a class="moz-txt-link-rfc2396E" href="mailto:dirk@lug-erding.de"><dirk@lug-erding.de></a> said:
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""> > And of course: A collection of known problems and work-arounds would
> be nice. <<SNIP>>
so feel free to improve this page or use the wiki.</pre>
</blockquote>
I'd like to suggest MAYBE "more" is not "all better". My reality
is that it may take quite a few repeat executions to get the data
perfectly correct. As I pursue my personal objectives for FAI,
I've been faced with questions like:<br>
<ul>
<li>Is is safe to re-run fai-setup without re-installing from
scratch? Under what circumstances is it required to run
fai-setup again? How do I reconcile a statements in existing
documentation "Run fai-setup only once" and "after ??? run
fai-setup" (exact sources not remembered).</li>
<li>Why does fai-make-nfsroot need a specific choice in kernel
version when version spec is not required during fai-setup?</li>
</ul>
These are trivial examples of procedural level questions where
design governs the answer. Answers are made difficult by the
flexibility that FAI is famous for. I find the "walkthrough" type
document to be hugely valuable. Yet I need to underscore the
thoughts:<br>
<ol>
<li>Documentation as a whole needs consideration because new
users need to know what advise to trust and what advise does
not apply in the circumstance. Perhaps a smaller current
document collection with a large structured archive of
superseded content is useful?<br>
</li>
<li>FAI is part of a moving target so documents need rev level
and date reference because all nubies are not using a single
rev at one time.</li>
<li>I'm glad that the words "up-to-date" docs was not the focus
because covering all the variation is daunting. It's more
like a cluster of bees with FAI being the nest. I'm blowing
smoke? [I could not resist]<br>
</li>
</ol>
I know there is more to the list, but is seems worthwhile to start
it. <br>
<br>
I have seen the wiki to be useful as a framework for documentation
because of the built-in concepts -- page content is subject to
revision more than replacement (as in publishing a new users
manual), and sample file attachments are easy. It has a strong
upside for community if it is structured for it. The down side of
wiki is the contributor who is off-base technically and the one
who presents without concern for the experience level of the
reader. When a specific outcome is desired, user
experience-to-date is the filter for documentation content. And
perhaps the worst downside is apathy.<br>
<br>
FAI is in no way a plug-n-play application. Sticking with that
thought, the value of walk-through and a fool-proof set of example
data is golden. The more the merrier? For new users who grew
into Linux from other distros it is also tough to bring one
environment (?Debian at squeeze rev?) to the table as the platform
for FAI. It's my experience that the Ubuntu 3.4.8ubuntu2 version
is also not plug-n-play and I'm a little challenged by the quote
"...nobody cares about Ubuntu...". As an aside: I also become
curious when I find a history where mounting FAI on Fedora
[something more like UNIX V5?] becomes hugely frustrating and
abandon. Therefore to wrap up all these experiences into one
result -- many walk-though sample cases with many platforms
contributed by many users as they join the main stream is perhaps
the most helpful to the newbie success story.<br>
<br>
AND it is not all about nubies. Try moving from rev to rev when
longevity and heterogeneous environments come into play. Building
a homogeneous cluster needs to be one test-case as well as
building the next distro [say CentOs follows Debian?] or the next
archetecture [say AMD64 follows PowerPC?]. Certainly there are
combinations that don't work so where might I find the matrix that
exhibits past successes? My desire? -- platform distro, FAI
server distro, FAI client distro, archetecture, [others], are all
things my math-major friends call "independent variables", and I
need to learn about those that work before I experiment with those
that are new but better fit my objectives.<br>
<br>
Sorry to have beaten examples to death. It's more about user
community experience than core project authorship. It's also
"learn by following"? For my own part I will gladly contribute my
success story soon as I find one. I'm hoping FAI permits me to
define all(?) hosts on the LAN for the long run instead of
piecemeal project for each host and rev. I also hope someday DHCP
will permit "build in place" in favor of "build on subnet". If
it's any value I might be able to support an on-going test bed to
run selected FAI variations against so that FAI might become
closer to plug-n-play.<br>
<br>
Thanks & cheers.<br>
Geo<br>
</div>
</body>
</html>