Please don't forget that we already have a database for SIS. Its
currently part of the SystemInstaller rpm. It can be easily extended to
hold the data that is needed. We should leverage this instead of
creating another data store in SystemImager.
Mike
On Tue, 2003-02-11 at 13:05, dann frazier wrote:
> (Adding sisuite-devel to the cc: list)
>
> On Mon, Feb 10, 2003 at 11:25:35PM -0600, Brian Elliott Finley wrote:
> > Gary,
> >
> > I've read and digested all of your thoughts below. I like the overall
> > concept, and I think I like a number of the potential implementation
> > ideas you mention below.
> >
> > Specifically, I like:
> > * The idea of having a database for tracking client information
> > -- this ties in nicely to some design ideas that are currently
> > on the table.
> > * The database being a text based database.
> > * Breaking up the autoinstall scripts into components, and
> > having clients pull the pieces they need.
> > * The idea of eliminating the symlink "database".
> > * The EXTRA_SCRIPTs idea -- being able to call arbitrary scripts
> > from within the autoinstall script framework.
>
> no disagreement here, i definitely think we can evolve to that point.
> i think we should put together a planned set of phases to get to where
> we want to go. imo, these phases shouldn't be carved in stone, and
> should be independent of stable releases (as much as they can, avoiding a
> painful upgrade processes in intermediate releases).
>
> for example (and just an example - these phases are arbitrary):
>
> phase 1 could be having a config file for each clienttype, which
> contains all meta information - /etc/sis/clientdefs/<mastername>.
> mkautoinstallscript could use that information for generating master scripts
> (which would definitely help upgrades).
>
> phase 2 could be removing the symlinks, and having a config file(s) that
> associates nodes with images.
>
> phase 3 could be adding /etc/sis/partitionschemes/, and referencing them
> from within /etc/sis/clientdefs/<mastername>.
>
> phase 4 could be adding a PRE_INSTALL / POST_INSTALL options to the clientdefs
> configs, to enable adding arbitrary scripts, and having a defined environment
> for those scripts (you can find your IP in the IPADDR variable, etc).
>
> phase 5 could be breaking up the master script and eliminating its need
> to exist (and therefore the need to be regenerating), by making the install
> client smart enough to grabbing the appropriate pieces it needs at runtime.
>
> this evolution could take a week, and make the next release, or a few months,
> and be spread over a couple releases, but would allow us to keep things in
> a pretty-much-releasable-state at all times.
>
> if this phased approach makes sense, i'd be glad to write-up a more formal
> outline of possible phases, and a brief summary of each, then we can discuss
> the outline, and began adding more detail (here's the options in config
> file foo we'll support, and how we'll upgrade from earlier versions, etc) until
> it becomes a plan.
>
> --------
> For the benefit of the sisuite-devel list:
> Thoughts on text "database" for install information.
>
> We talked about having the install server send out a "database" with the information
>for the install in it. I propose using something like:
>
> boel_ia64 port=9837,mcast_addr=225.1.2.7
> boel_i386 port=9848,mcast_addr=225.1.2.8
> image-of-the-day port=9283,mcast_addr=225.1.2.8
> .
> .
> .
>
> with a single line per database entry. This is in the "genders" format used by LLNL.
> I have a simple shell script that will pull out information like:
>
> # genquery -f filename -v boel_ia64 port
> 9837
> # genquery -f filename -v boel_ia64 mcast_addr
> 225.1.2.7
>
> We have thoughts of using something like this to help manage configuration
>differences. I think that in many ways this same file format could be used in helping
>reduce the number of symlinks in the scripts directory. Instead of the "symlink"
>database used now in the scripts directory, the necessary information could be put in
>a "database" file with all of the information a node needs to install. This could
>include other information specific to a site so that they could use this same
>database for determining other node information.
>
> hostA
>SIimagename=image-of-the-day,overrides=override1:override2:override3,postInst=whatever,eth1ip=192.168.34.87,partitiontype=A+C,adminnode,thinnode,whatever,...
>
> I've been pondering on how to make the script thing work easier for us here and I
>thought I'd bounce some ideas off of you. We have a few different node types and I
>don't want to maintain a separate .master file for each of them, since many of them
>have similarities. I have:
>
> Thin-nodes (2x36G disks in a RAID1 config)
> Compute nodes (partition type A)
> -> Some of the following also have a single 72G disk <-
> Admin nodes (partition type B)
> login nodes (partition type A)
>
> San nodes. (2x36G internal disks with extra SAN)
> osd nodes (Maybe type A for internal disks, maybe not...)
> mds nodes (maybe like an ost maybe not.)
>
> Fat-nodes (2x36G disks in RAID1 {partition type A}
> + 4x72G disks in RAID0)
> Compute nodes
>
> And probably a few other types that I don't remember at the moment.
>
> For my purposes, I want all of the compute nodes to be identical except for the
>differences in the disk configuration. If I look at a diff of the files on the two
>systems, the only difference should be the raidtab, but the install requires more
>differences because of the partition information. Other images will also have
>similarities and differences between each other.
>
> I can create a separate autoinstallscript.conf file for each of these, but that
>seems like a bother when most of the stuff is the same. Besides that, I ended up
>putting a bunch of custom stuff in my .master script to deal with making a second
>boot entry for a backup efi filesystem and also dealing with SystemConfigurator
>giving me long hostnames rather than short ones etc. If I run the
>mkautoinstallscript, it wipes out my changes.
>
> Soooo, I wondered if it would be possible to maintain the partition information in a
>set of files and have the install script "know" which one to use for a particular
>node.
>
> The overrides could be gotten from the database without needing to put them into the
>.master file. The fstab could be put into an override directory just as easily as
>putting it in the .master file. Similarly the systemconfigurator options (for
>differences in network or boot config) could be an added option. In the end, there
>should only need to be one .master script. All of the parts would be somewhere else
>and could be used in a mix of match way.
>
> So with a scripts directory like:
>
> scripts/masterType1.master
> scripts/masterType2.master
> scripts/nodeDB.txt
> scripts/partition/A
> scripts/partition/B
> scripts/partition/C
> scripts/partition/D
> overrides/compute/fstab
> ....
> overrides/thin/etc/raidtab
> ....
> overrides/fat/etc/raidtab
> ....
> overrides/admin/...
>
> a .master file could look something like:
>
> IMAGENAME=$(genquery -f scripts/nodeDB.txt -v nodename SIimagename)
> OVERRIDES=$(genquery -f scripts/nodeDB.txt -v nodename overrides | sed '/:/ /g')
> PARTS=$(genquery -f scripts/nodeDB.txt -v nodename partition | sed '/+/ /g')
> EXTRA_SCRIPTS=$(genquery -f scripts/nodeDB.txt -v nodename extra_scripts | sed '/:/
>/g')
>
> for PART in $PARTS
> do
> scripts/partition/$part
> done
>
> # That should have partitioned the disk and mounted the filesystems.
> if [ MULTICAST ]
> then
> ...
> else
> rsync WHEREVER/$IMAGENAME /a
> for OVER in $OVERRIDES
> do
> rsync WHEREVER/$OVER /a
> done
> fi
>
> foreach SCRIPT in "$EXTRA_SCRIPTS
> do
> scripts/$SCRIPT
> done
>
> umount filesystems
> rebootORwait
>
> -----
> Gary Skouson
--
Michael Chase-Salerno <[EMAIL PROTECTED]>
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Sisuite-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
