Hi, some good point
Cordialement / Vriendelijke Groeten / Best Regards / Med Vänliga Hälsningar
Tore Agblad
Volvo Information Technology
Infrastructure Mainframe Design & Development
SE-405 08, Gothenburg Sweden
http://www.volvo.com/volvoit/global/en-gb/
________________________________________
From: Linux on 390 Port [linux-...@vm.marist.edu] On Behalf Of Scott Rohling
[scott.rohl...@gmail.com]
Sent: Wednesday, June 10, 2009 06:00
To: LINUX-390@VM.MARIST.EDU
Subject: To kick or to clone ... that is the question
This is a blatant request for discussion about the pros and cons of using an
automated installation (e.g. RH kickstart - Suse autoyast (though maybe this
has changed - I'm not current on Suse) - vs cloning a system from a 'golden
image'... and I should say: on zSeries.
I'm a fan of kickstart - and I'll list my reasons in approximate order of
importantance to me (most to least):
- kickstart forces a scripted and recreatable installation. You specify
the rpm's and can do some limited scripting within the kickstart file itself
to end up with (hopefully) a working Linux system that requires no manual
tweaking (at least - if you do it 'right'). The alternative is a cloned
system that the Linux SA's have been on, and perhaps several other teams -
all performing manual tasks to end up with the final product - all sorts of
shoeprints and no good detectives. Whereas a kickstart config is
self-documenting - a clone is not. With good scripting and good use of rpm
packaging for your 'local' or even 'vendor' products - you can end up with a
very KISS config file that might even go multiplatform. (e.g. arch=`uname
-m` )
- with a proper building of conf and parm files on z/VM - a guest can be
kicked already configured with a working network -- no need for some outside
scripting or manual config.
- you can have different kickstart files for different server 'types' (web,
app, db, etc) - these can even be built dynamically and requested via a URL
to to the kickstart ( e.g.
http://mykicker/kick.web&ip=xx.xx.xx.xx+etc+etc.....)
- The size of the DASD can be flexible.. cloning requires copying the same
size DASD as the source..
- The latest fixes can be applied by keeping the repository the kickstart
uses current - rather than updating a clone source. (of course - testing is
still required and would require kickstarting a guest to truly do any
testing - a good thing imo)
- It encourages packing by rpm rather than manual 'tarball' methods.. this
is in line with a 'recreatable' install. Yes, you can still do 'tar'
commands in the kickstart file itself.. but specifying an rpm package is oh
so much easier.
- Servers start 'clean' - ie no old log files from the clone source and no
need to try and script a 'cleanup'
- No worrying about whether a clone source is 'up' when a new server is
clone and possibly clone a live system
There are downsides.. but I'll leave those to the rest of you to expound
on, since I'm taking a position of 'kickstart good, Jane'
Thanks and hope this is valuable to some ..
Scott
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
