On Mon, May 10, 2004 at 09:44:16AM -0700, Lombard, David N wrote:
> 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.
To be clear, the only thing I see in your patch that conflicts with the
methodology is where/how its configured. I like the idea of someone
knowing that if they wanna tweak how the disk is partitioned or the filesystems
are created, they edit their autoinstallscript.conf file. Whether this means
changing an fs from ext3 to reiser, making their /usr partition bigger, or
making disk type detection automatic or static.
> ============
> > maintain autoinstallscript.conf files for each partition/fs
> configuration.
>
> ========================================================================
> ==
>
> I've underlined the specific problem being addressed by this patch.
Yes, I wrote that as an acknowledgement of the problem, and to outline
what I see as the benefit of your patch - I think autodetection is a great
idea.
> 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.
I don't know that a real autodetect files/links need to exist, the master
script would just be populated with your autodetect code in this case.
I intended the word "autodetect" to be a keyword.
After some thinking, its certainly a bad idea to let users mix & match
autodetect & non, so this would probably need to be a global flag somewhere
in the autoinstallscript.conf file instead of a per-partition option.
> 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.
I can see a site needing to use different values for different types
of machines - of course, you could just use multiple template files.
I'd personally prefer to see multiple autoinstallscript.conf files.
It makes upgrades smoother, since users need to merge their changes to
templates files forward, yet autoinstallscript.conf should be backwards
compatible.
> 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.
sure, but a bug in the initrd is a lot harder for a user to fix/workaround
than a bug in a server perl script. i love the idea of using /proc/cmdline
to pass options for things needed up to the point of getting the master
script, but once you can get a master script, its better to cut the cord.
doing it in the master script (or its generation, to be specific), is also
consistent across architectures/boot methods.
> 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.
agreed.
> My patch implements one method;
> clearly there are other implementations which meet these requirements
> and your needs.
-------------------------------------------------------
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
