(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
--
---------------------------
dann frazier
Hewlett-Packard
Linux Systems Division
[EMAIL PROTECTED]
(970) 898-0800
-------------------------------------------------------
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
