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. This provides an extremeley granular layer of customizability, but trades off ease of use. The solution you've implemented sounds more like old-school SI, where things *just work*, and you don't need much expertise to get your nodes installed. The problem I see is that its a completely different way to do something you can already do, and I'd really like to see the project sticking to a methodology and adding features within it, rather than inventing something new for each problem we try to solve. 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. 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. On Fri, May 07, 2004 at 03:25:19PM -0700, Lombard, David N wrote: > I've developed a patch for SystemImager 3.1.4 (I also have an untested > 3.2.0 patch) which permits a single image to support clients with > differing disk types, e.g., SCSI v. ATA, cciss v. rd. The patches are > available at > > http://www.lombardsnest.com/dnl/OSCAR/ > > As you might guess by the above URL, the patches were specifically > developed for OSCAR, and have been tested with OSCAR 3.0 using VMware. > > > To incorporate the capability, apply the patch and pull a new image. > The new image master scripts, e.g., /var/lib/systemimager/scripts/*.sh, > will no longer use hardwired device names like /dev/sda to partition or > format disks; instead, the master script will use shell variables and > refer to disks as "$DISKi" and partitions as "${DISKi}p", where i is an > index ordering the disks per internal SystemImager conventions and p is > a literal partition suffix, e.g., "1" or "p1". The shell variables, > e.g., $DISKi, will be resolved into actual device names when the image > is loaded onto a node. The resolution process will consider disk devices > based on the type, e.g., all ATA, all SCSI, and all hardware RAID; more > specifically, the abstraction works for sd, hd, cciss, ida, and rd > devices. Software RAID devices, e.g., /dev/md* are fully supported. > > The default disk ordering, > > DISKORDER=hd,sd,cciss,ida,rd > > will select disks in the order > > /dev/hd* > /dev/sd* > /dev/cciss/c*d* > /dev/ida/c*d* > /dev/rd/c*d* > > Notes: > > 1) Alternative disk ordering, e.g., selecting SCSI devices before ATA, > can be specified using the DISKORDER kernel parameter. For example, > specifying > > DISKORDER=sd,hd > > on the APPEND line of /tftpboot/pxelinux.cfg/default will consider SCSI > before ATA devices and ignore all hardware RAID devices. The following > keywords may be used with DISKORDER: > > hd > sd > cciss > ida > rd > > Use of other keywords, or non-lower-case keywords will cause a shellout > call. Keywords are separated with commas. The keyword string is > sanitized before use, which should remove spaces, extra commas, &etc. > > 2) You can disable disk auto-detection/ordering, and revert to the > original disk assignments by specifying "DISKORDER=", i.e., defining a > NULL value. Note, this doesn't disable the new code, it specifies the > original assignments whence the image was pulled. As you can see, a > distinction is made between DISKORDER being unset, which invokes the > default ordering, v. a null value, which disables the reordering. > > 3) For sd, cciss, ida, and rd devices, the correct device ordering will > be used for multi-letter/digit names, e.g., /dev/sdz will precede > /dev/sdaa, and /dev/cciss/c0d9 will precede /dev/cciss/c0d10; note this > is contrary to the alpha sort used by the shell and ls. > > 4) The /etc/raidtab used by the initrd is similarly handled with $DISKi > names. The image's /etc/fstab, /etc/raidtab, and > /etc/systemconfig/systemconfig.conf files are all edited to implement > the appropriate changes. See also the following note. > > 5) There are no limitations on the combinations of disk names changed, > i.e., "/dev/hda" and "/dev/sda" devices are properly interchanged via > "DISKORDER=hd,sd" and "DISKORDER=sd,hd". > > 6) There is a limitation in disk ordering, i.e., you cannot intermingle > devices, e.g., /dev/hda, /dev/sda, /dev/hdb. However, if the client was > imaged with such an arrangement, the patch will faithfully reproduce > that when disk ordering is disabled as described in (2) above. > > > For testing, I used OSCAR 3.0 (with an OSCAR-specific variant of the > patch) under VMware as follows: > > NOTE: While cciss, ida, and rd devices are supported, I have not > actually tested any systems that contain these devices. > > 1) Install a cluster normally. Both the server and client node had a > single SCSI disk. > > 2) Modify client: remove SCSI, add IDE disk. Loaded client w/ hda root. > > 3) Remove all disks. Negative test passed (no disk). > > 4) Modify client: add two 100MB SCSI devices. Negative test passed > (disk too small). > > 5) Modify client: add IDE disk. Client reloaded with extra, untouched > SCSI disks. Loaded client w/ hda root, sda/sdb unused. > > 6) Manually modify client to add RAID-0 md0. Pulled image using > getimage after shutting pfilter off on both server and client. Loaded > client w/ hda root and sda/sdb md0. > > 7) Modify client: remove scsi disks, add two 100MB ide disks. Loaded > client w/ hda root, hdb/hdd md0. > > 8) Modify client: Remove all disks, add scsi root and two scsi md0. > Loaded client (sda root, sdb/sdc md0). > > 9) Modify client: Add hda root and two 100 MB ide disks, hdb and hdd. > Modify server: Added "DISKORDER=" to /tftpboot/pxelinux.cfg/default. > Loaded client w/ hda root and sdb/sdb md0 (see 6 for built-in order), > i.e., hdb and hdd were ignored. > > 10) Modify server: Added DISKORDER=sd,hd to > /tftpboot/pxelinux.cfg/default Loaded client, hda root, hdb/hdd md0. > > > -- > 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 > ------------------------------------------------------- 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
