> -----Original Message-----
> From: Sean Dague [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 12, 2003 6:22 AM
> To: dann frazier
> Cc: Brian Elliott Finley; Skouson, Gary B; Tenney, Nathan D;
> sisuite-devel
> Subject: Re: [Sisuite-devel] Re: Random SystemImager thoughts (Sorry
> it's kind of long)
>
> Flat file DB doesn't scale. Its why we went to dbm files
> that are keyed.
> At even a hundred clients, doing db operations on the server
> starts to suck
> without this. We've got a test battery that is run against
> the current db
> doing a 5000 client set, inserts, selects, deletes, updates,
> and are fairly
> convinced that this is the right way to go. Above 5000, we
> really need to
> connect to a really RDBMS.
If you have 5000 files needing information from a single install server,
the database load is probably not the main concern at that point. Trying
to load all 5000 in a small amount of time will be a bigger problem. If
it's a text file and the client gets its own information from the file,
you have kind of a distributed DB. It doesn't matter as much if it's a
bit slow.
>
> > and another option is a mechanism by which the client could
> query the remote
> > database, and get the information in a parseable form -
> this is what i'd
> > prefer - leaving as much complexity on the server as possible.
>
> I'm going to give this one last college try....
>
> KEEP IT SIMPLE
>
> The reason that BOEL is nice, and works, is because what it
> does it really
> simple. There is a script, and the script goes from A -> B
> -> C, and its
> really clear what it does.
I agree that it should be simple. I really don't thing that there needs
to much of a change to BOEL. I'm thinking more of the way that the
.master script works. Right now the .master scripts are a bit of a pain
and I was looking for something that would make things easier for me.
> KEEP IT SIMPLE
>
> If you want to add any complexity, do it on the server. Load
> up the db with
> attributes, generalize out everything in the autoinstall
> script (including
> disks). The Database and tools can easily manager 1
> autoinstallscript per
> machine in a way that *all just works*.
>
> Want to point a client at a new image?
>
> mksimachine -U --name=$client --image=$image --genautoinstall
>
> Done! All the complexity for managing N numbers of machines,
> is handled in
> Perl (as opposed to Ash), on the Server, where an error can
> be recovered and
> presented to the user.
>
> Want to have arbitrary grouping? No problem, that's one Mike
> C-S's plate
> already at the moment.
>
> The problem I'm seeing here is there is an attempt to try to
> create ways
> arround the SIS infrastructure for edge cases, instead of
> saying that those
> are real requirements, and how do we build and interface to
> support them,
> and an engine to implement them.
That sounds great, but I haven't had a lot of success in having the
auto-generated .master script get me the image I need. The scripts get
me a system that's close, but I always seem to need to edit something to
get something set up like I need. Unfortunately the changes I need to
make need to be made to each of the .master scripts. That's usually
only a handful, but it's a pain, especially when I miss one.
I could code these changes into the normal generation code, but it seems
that in continuing to add special cases to the script generation code
Ill eventually end up with more command line options than gcc.
So, I was thinking about ways to modularize the .master script. Mostly
the install script for a node does:
partition the disk
mount the filesystems
put the OS on
do some override stuff
add the /etc/fstab
run systemconfigurator
let the server know we're done
unmount things
reboot/wait etc.
With some kind of simple database, it seems like it would be easy for a
generic .master file to determine if nodeA needs partition scheme a,b,c
or d. If the image we want to install is 1,2 or 3, what overrides to
apply etc. It would also give a way to add another step in there
somewhere to do some extra "site specific" stuff.
Maybe I'm just one of those "edge cases". I'm fine with that. I agree
that it's impossible to support every edge case and you're better off
looking at what's in the best interest of the most users. I've been
working around things so far, and we'll eventually do something here at
our site that works for us. Mostly I'm interested on how the future SI
stuff is planning to deal with things. If there's something in the
works that I can use and extend to fill my needs, I'd rather do that
than go off and do something that'll never work on a future SI version.
It's been great to see the concerns and ideas that others have had.
-----
Gary Skouson
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Sisuite-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
