On Tue, Mar 29, 2005 at 05:51:07PM +0200, Erich Focht wrote: > On Tuesday 29 March 2005 17:28, Sean Dague wrote: > > On Tue, Mar 29, 2005 at 04:01:19PM +0200, Andrea Righi wrote: > > > So to cover as many cases as possibile, probably, we should consider > > > different network configurations (up to one for each interface). > > > > > > The solution proposed by Brian is good, but it introduces a new config > > > file. > > > > > > The Erich's solution sounds good, but forces to use always > > > SystemInstaller package (due to SIS DB dependency). > > > > My own personal opinion is that SystemInstaller solved the problem already, > > and using that as the front end if you want this functionality is the right > > approach. What is wrong with using SystemInstaller? > > > > Anything that reinvents this all over again is largely a waste of time. > > I'm not sure whether you argue against sis_reload or not. The SI > release I can access and download is version 1.04 and that one has > huge deficits when it comes to multiple interfaces. I was trying to > solve that problem by using the SIS infrastructure and database, as > well as systemconfigurator for loading the changes into the > clients. The SIS infrastructure is prepared for multiple interfaces, > but I needed something like sisqd/sisqc to access it from the client > nodes. If there is another way, please explain it.
I'm not sure that sis_reload is the right approach. My personal feeling is
that this information should come from the SIS db and be incorporated into
the autoinstall scripts directly by systemimager. Right now there are too
many instances of having to go around the autoinstall scripts to get things
done, when it is clearly what should own/drive the install process. Put it
in the main path, then it will tend to be more maintained.
> > > However if we will use the SIS DB we could generate the
> > > systemconfigurator config file when the autoinstallscript is generated;
> > > I mean the Server.pm should include the code to parse the SIS DB and
> > > produce the list of interfaces to pass to systemconfigurator, instead of
> > > using the infrastructure with sisqd and sisqc proposed by Erich. I think
> > > this infrastructure could be useful as an "extension" (look to autoconf
> > > stuff...), but IMHO it shouldn't be mandatory...
> >
> > You don't just need parsing, you need a way to put that info in there... and
> > that way is SystemInstaller. Just use it.
>
> Yes, the parsing is what I wanted to avoid. Otherwise one ends up with
> a huge bunch of additional perl packages which need to be installed on
> the cluster nodes, too.
Yep, doing all the generation on the head node should be the right approach.
-Sean
--
__________________________________________________________________
Sean Dague Mid-Hudson Valley
sean at dague dot net Linux Users Group
http://dague.net http://mhvlug.org
There is no silver bullet. Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
pgpSLvZMCtMsx.pgp
Description: PGP signature
