This was all discussed at some length when the design req first came out. I and others argued strongly for begin and finish as the "HOOK" for the unexpected, along with concrete examples. They were unpersuadable. I gave up.
I decided I would create an IPS package which would provide the finish script functionality to mimic Jumpstart after the fact...... Mike Bill Walker wrote: > > OK, so using my previous examples: > > (1) I need to install some stuff (third party and other goodies) that > needs to be installed and configured before booting into the visible > production network. The stuff is ISV or of other interesting sources, > and isn't adhering to our packaging rules/guidelines. (current solution > is a post-install script that extracts and runs config scripts that > figure out that to do based on some system and install profile info) > > (2) I need to install some drivers, and possibly even flash some > firmware to a device (say a third party SAN driver), and can only do the > configuration and "attach" type functions once the device tree and > software configs for the device and capabilities of the device is > currently installed. (current solution is to do post install scripts, > possibly with a couple RCs and reboots) > > (3) I copy in "standard configurations" from an external store (say > RCS, PVCS, NFS, etc.) for a pile of services, applications, and local > grown apps depending on some system config and application config logic. > I don't want to do this by hand 1000 times, and I don't want manual > intervention or opportunities for "fat fingering" by deployment staff. > > I'd love to have some easier ways to do stuff, and I am not against any > changes that make things simpler or more efficient. Unfortunately, with > the plethora of ISVs and existing investments in deployment frameworks, > one size definitely will not suit all (or even many). Having > flexibility to "make exceptions" while doing installs is actually (in my > experience) a vast majority thing, and since these "post install > activities" are soooooo varied and complex between systems and > customers, scripting the voodoo somehow has always been the simplest and > most flexible option. Expect exceptions. :) > > bill. > > > > Glenn Lagasse wrote: >> * Lubomir Sedlacik (Lubomir.Sedlacik at Sun.COM) wrote: >>> Casper.Dik at Sun.COM wrote: >>>>> No, at this time those do not exist. That's deliberate. In many >>>>> (most) cases, Jumpstart finish scripts exist to work around gaps in >>>>> the feature set or implementation. We want to understand what the >>>>> real requirements are and build those into the product. >>>> Don't try that; after reading a large part of the AI opensolaris >>>> autoinstallation documentation I can only conclude that people have >>>> read the jumpstart installation but they have no idea how jumpstart >>>> is used in practice. >>>> >>>> First of all, everyone who uses jumpstart in a large environment >>>> doesn't actually need to do anything when a new client is installed. >>>> >>>> Secondly, in a past live, I used the begin/finish script to customize >>>> *everything* in a system. >>> Seconded. >>> >>> E.g., at Solaris System Test we perform several hundreds of >>> different JumpStart installations (and upgrades) every week on a lab >>> of ~400 machines. Install begin/finish scripts give us the >>> flexibility to implement any customization we need, often being >>> creative to work around bugs in various development builds which >>> actually allows us to install the system and don't just pronounce >>> the build dead in the water and drop testing. This functionality is >>> absolutely essential for us. >>> >>> Lack of begin/finish script functionality would have a huge impact >>> on productivity of many teams in the company, forcing them to >>> implement various home brew workarounds since their requirements are >>> unlikely to change. >> >> So, what exactly are people not understanding when we (the install team >> working on this stuff) say 'provide us with concrete *requirements* of >> what you *need* and not what you want'? And saying 'we want jumpstart' >> doesn't count. Technology changes and moves on (and hopefully evolves >> and gets better). >> >> The lack of begin/finish script functionality *may* have an impact on >> teams if we don't actually provide some other mechanism that >> accomplishes the same tasks that people have been using the begin/finish >> script functionality in jumpstart for. But until we get people to 'look >> at the problem objectively' and provide us with useful data (real >> requirements) instead of just saying 'we want begin/finish scripts' >> we're not going to get anywhere. >> >> AI is different, intentionally so. Among other things, we're actually >> trying to improve automated installation of OpenSolaris. Begin/finish >> scripts was one possible solution to a myriad of problems. Surely since >> we're dealing with computers (that do what we program them to do) we can >> define the problems that the begin/finish script solution solved and >> implement better solutions for each problem rather than having the hodge >> podge solution of people writing their own scripts that Sun then can't >> easily support? Maybe we can't come up with solutions, but until people >> work with us by providing concrete requirements (other than just 'we >> want begin/finish scripts') so that we can actually engineer something >> we'll never know. >> >> My .02. >> > -- Mike Ramchand Principal Field Technologist Systems Practice Sun Microsystems (UK) Tel: +44 125 2421091, Ext: (70)21091, Mob: +44 780 1179593 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature URL: <http://mail.opensolaris.org/pipermail/desktop-discuss/attachments/20090325/f44ec95c/attachment.bin>
