Ian Stokes-Rees wrote:
> Finally, has anyone stepped back and said "It shouldn't be this
> complicated"? I constantly think to a few years down the road where
> (presumably) there will be lots of large clusters, in essentially
> continuous usage, and there will be continuous hardware replacement.
> Clusters will be full of "ever-so-slightly" to "quite-dramatically"
> different worker nodes. I can't imagine it will be possible to do
> "global" grid re-deployments of all software, so multiple software
> versions (of the grid middleware) will *have* to co-exist. Sys admins
> will just have to get on with maintaining their own sites with their own
> techniques and to the best of their ability and resource. Does Quattor
> make this easier or harder? Is it an "all or nothing"
> installation/deployment manager like LCFGng?
I don't want to get into the general discussion, but just a few comments
on Quattor:
* It is much more componentised than LCFGng, especially on the server
side. It is easier to just use the bits that are useful to you.
* Much of the complexity and flakiness that scared people at the CERN
tutorial was due to the use of the Quattor command line tools and software
repository management. We have ditched most of that and are just using our
existing CVS for managing and a basic web server for the repository and it
makes life much easier. The server is basically just a simple web server
and the profiles can be compiled anywhere (not like LCFG where they
effectively could only be compiled on the install server).
* It already supports configuration of more OS and LCG components than
LCFGng did (one of the things I found annoying about LCFGng were that it
was missing the last 5% of components which meant you still had to run
through some manual steps each time).
Having said all that I wouldn't recommend Quattor for a single small site:
the overhead of learning Quattor isn't worthwhile in this case. For
someone managing a collection of sites (as we are -- 18 now!) or a single
large site I think it's worth the effort to have a single location for all
configuration information, and fine-grained control over node configurations.
Stephen
--
Dr. Stephen Childs,
Research Fellow, EGEE Project, phone: +353-1-6081797
Computer Architecture Group, email: Stephen.Childs @ cs.tcd.ie
Trinity College Dublin, Ireland web: http://www.cs.tcd.ie/Stephen.Childs
|