--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Feb 12, 2003 at 12:49:22AM -0700, dann frazier wrote:
> On Tue, Feb 11, 2003 at 10:34:41PM -0600, Brian Elliott Finley wrote:
> > Therefore:
> >=20
> > * What if we were to include perl in the boel_binaries.tar.gz?
>=20
> perl is a beast - i'd like to avoid this if at all possible (shocking, hu=
h?)
> keep in mind this is all running in a ramdisk on the client - perl binari=
es +
> libraries + the memory it takes up at runtime.
>=20
> i remember sean mentioning some embedded perl project(s) - what kind of
> overhead do they incur? what are they missing vs. a full perl distro?
Embedding perl is something I'd like to stay away from for 2 reasons:
1. Space Concerns like Dann Mentioned
2. Complexity of BOEL
=20
> another concern is architecture portability of the perl interpreter we
> choose.
Not really an issue. Perl runs on every platfrom known to man (including
Palm Pilot and S/390 Native), and correctly written perl code will run on
all versions of Perl released since 1998.
> based on doing backports of the debian perl package, i can say it will
> likely increase build times substantially, but this is a minor concern.
>=20
> > * What if the master database was based on the current SIS db,
> > and whenever it was updated, a small chunk of the data (just
> > enough to provide a client info on where to find the
> > appropriate boel_binaries.tar.gz) was written to a separate
> > file in a plain text db format (ala Gary's example)?
>=20
> another option is to make SIS use a plain text db format that can be
> parsed in shell.
Flat file DB doesn't scale. Its why we went to dbm files that are keyed.=
=20
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.
=20
> and another option is a mechanism by which the client could query the rem=
ote
> 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.
For a science project it would be neat to build this cool little engine that
connects to a couple different servers, figures out what it should do, and
makes sure it all happens. The problem is, if anything goes wrong, it is no
longer very clear how to fix it. Support becomes a nightmare, and anyone
who downloads the code and doesn't have it work the first time labels the
project as a POS for all eternity (even if the fix *was* in CVS).
This would lead to even *longer* release cycles, hence a slower moving
project, and more areas of the code that you can accidently blow the whole
system by forgetting a space. What is more unfortunate, is it would create
an exponentially increasing number of code paths that would not be tested
during a release cycle.
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=3D$client --image=3D$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.
Putting more function in BOEL, is like pushing core OS function into the
BIOS. Sure, it's nice if X would come up from the BIOS, but if you ever
have to change X, its a painful process to do so. Building BOEL is a pain
in the arse, and telling customers that they have to do it isn't acceptable.
Making a fix on the server is really easy in comparison. =20
Ok, I'm going to stop my rant, and go back to my day job. But please
strongly consider the support issues of any new solution before going down
any road.
-Sean
--=20
_______________________________________________________________________
=09
Sean Dague [EMAIL PROTECTED] http://dague.net
There is no silver bullet. Plus, werewolves make better neighbors than
zombies, and they tend to keep the vampire population down.
_______________________________________________________________________
--y0ulUmNC+osPPQO6
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE+SliYSamXem9TdyYRAqncAKCzBDhRB1qhkLreFlTU3fvkMG13bACeIicm
k0HfshqxSX6xXoCpdj0ox2M=
=9nwI
-----END PGP SIGNATURE-----
--y0ulUmNC+osPPQO6--
-------------------------------------------------------
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
