I find this entire thread to be huge gentlemen.
It has everything to do with my nubie status with FAI plus end user
community.
On 03/12/2013 06:36 AM, Thomas Lange wrote:
On Tue, 12 Mar 2013 11:26:45 +0100, Dirk Geschke<d...@lug-erding.de> said:
> 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.
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:
* 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).
* Why does fai-make-nfsroot need a specific choice in kernel version
when version spec is not required during fai-setup?
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:
1. 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?
2. 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.
3. 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]
I know there is more to the list, but is seems worthwhile to start it.
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.
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.
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.
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.
Thanks & cheers.
Geo
