From: dann frazier; Saturday, May 08, 2004 3:06 PM
>
> Thanks David. This is more Brian's area, but here's my thoughts about
> this.
>
> I think the way you solved this problem is a good one; however SI
> currently
> has a solution implemented that works by having users create
> multiple master scripts for single image, requiring them to modify and
============
> maintain autoinstallscript.conf files for each partition/fs
configuration.
========================================================================
==
I've underlined the specific problem being addressed by this patch. The
two master scripts suggested by the above, i.e., the originally
generated master script or a regenerated one with an alternate disk
configuration, are indistinguishable from one another and provide no
solution to the problem being addressed.
This patch does not require a-priori knowledge of the *exact* disk
configuration, as long as the variations are only among the disk
"names". For example, this supports differing types, e.g., hda v. sda,
and even controller cabling (hda and hdb v. hda and hdc).
> So... I'd like to see us find a way to decrease the usage difference
> between
> the two. We could make the autoinstallscript.conf files that are
> generated
> by prepareclient use a placeholder for a disk instead of the real disk
> name
> (maybe this behavior is chosen w/ a prepareclient flag).
>
> For example, instead of:
> <disk dev="/dev/hda"...>
> ...
> </disk>
> <disk dev="/dev/cciss/c0d0"...>
> ...
> </disk>
>
> we could do:
> <disk dev="/dev/autodetect0"...>
> ...
> </disk>
> <disk dev="/dev/autodetect1"...>
> ...
> </disk>
>
> If autodetect devices are specified, then your code is triggered.
> Something like this would maintain the methodology that "to change how
> your disks are partitioned, mess with the autoinstallscript file and
> regen your master scripts", but wouldn't require users to do so if
> all they wanna do is enable autodetection.
Remember, nothing I've done alters "the methodology" described above.
The only capability of this script is the latter -- disk autodetection;
not changing the per-disk partitions.
But your suggestion is fine -- it's really just an alternate
implementation of my patch. To implement this, the master script could
create links from the various /dev/autodetect{i} to the disks (not
forgetting about the partitions). You still need to deal with the files
on the newly-created image.
Enabling this capability via a prepareclient or getimage option is also
fine, with the latter being more flexible.
> Also, it seems to me that the DISKORDER option you've introduced would
> fit better in the autoinstallscript.conf file - prepareclient could
> spit out your default, and people can modify as necessary.
Perhaps. The default DISKORDER is already a part of the
autoinstallscript.template file, so the *default* could be changed there
on a per-site basis. The key is to avoid having to play with a single
master script that applies to multiple images.
A significant benefit of the kernel parameter is that it (a) permits
alternate DISKORDER settings at various granularities via pxelinux
config files, and (b) puts off the decision until you actually build a
node from the image.
Bottom line, I'd like to get a flexible ability to "not care" what
specific disks are available on any particular nod, as long as they meet
the size requirements of the image. My patch implements one method;
clearly there are other implementations which meet these requirements
and your needs.
--
David N. Lombard
My comments represent my opinions, not those of Intel Corporation.
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Sisuite-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
