Excellent - thanks, Brad -- I assume the code honors the kickstart 'reboot' option now on z?
Scott On Wed, Jun 10, 2009 at 8:22 AM, Brad Hinson <bhin...@redhat.com> wrote: > Scott Rohling wrote: > >> Hi Doug -- Yep, we sure had some fun kicking Linux servers! >> >> Not sure how Linux not doing restarting itself is an IBM issue... but >> that >> 'is' a nasty downside to kickstarting -- ending up at a 'You may safely >> reboot' screen doesn't help automation. >> >> > Reboot issue fixed in RHEL 5.3 :-) > > > And we should add that kickstarting is faster than cloning 'if' the DASD >> is >> already Linux formatted.. if not, the kickstart does the formatting, >> adding >> time to the install. >> >> Scot >> >> On Tue, Jun 9, 2009 at 11:39 PM, WILLIAM CARROLL <v...@smgvbest.com> >> wrote: >> >> Hi Scott, >>> >>> I'll jump on your bandwagon but then again you already know I perfer >>> Kickstarting over cloning >>> you should also mention that unless you have Flashcopy for your DASD >>> Kickstarting is actually faster than cloning. >>> unless your clone master is very small. >>> >>> as you recall ours was on a mod3 (lots of required garbage) and cloning >>> that mod3 was slower than kickstarting >>> also after the kickstart was done the server was ready, no additional >>> steps >>> to change IP's or anything. >>> >>> if only redhat would fix that re-ipl after the reboot. >>> they say it's an IBM issue not thiers >>> >>> Doug Carroll >>> >>> >>> >>> ----- Original Message ----- >>> From: "Scott Rohling" <scott.rohl...@gmail.com> >>> To: <LINUX-390@VM.MARIST.EDU> >>> Sent: Wednesday, June 10, 2009 12:00 AM >>> 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 >>> >>> >> ---------------------------------------------------------------------- >> 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 >> > > -- > Brad Hinson <bhin...@redhat.com> > Sr. Support Engineer Lead, System z > Red Hat, Inc. > (919) 754-4198 > www.redhat.com/z > > > ---------------------------------------------------------------------- > 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
