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. >
