On Wed, 2009-03-25 at 11:10 -0700, 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).
Did the examples Bill provided give enough info? What I *need* is a roof over my head, what I want is a house so your going to sell me a tent? Excellent. Begin and Finish scripts provide more functionality than you can ever foresee putting into your framework. Are you going to allow me to configure my disks based on system type prior to installation (raid for example)? Are you going to provide me a way to create a secondary zpool based on system type and disks using my business logic in an automated way? Are you going to allow me to reconfigure my network from where it's currently installed to where it will eventually be installed in a remote data center in an automated fashion so all I have to do is turn the system on and ship it when it powers itself off? Are you going to allow me to configure my SC for the same remote data center network? Are you going to allow me to upgrade my SC in an automated way during the install phase? Are you going to allow me to copy data from a NFS/FTP/WEB server to the system automatically during install, again based on my business logic? Are you going to allow me to re-provision a system for testing/qa work based on a FLAR? (No, no worries, I have a script for that thank you) Are you going to allow me to configure my web server? My data base? Which ones? My Application Server? You going to allow me to configure which SMF services to enable/disable, reconfigure upon install? How about adding service manifests? Yes - I did all of these things with my Jumpstart server as a System Admin of systems across the planet. > > 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. If you provide the functionality to expand past limitations in the system, you have a happy customer - this is what the begin/finish scripts provide. Customers (me being one of them) have been doing the equivalent of FLARs years before they were introduced into Solaris - with a begin script that basically took a ufs dump of a system and restored it to disk. How are you going to provide that level of innovation in your framework? As Casper mentioned, if you have to question the functionality of the begin/finish scripts, you've never really fully used jumpstart or understand the power it brings to jumpstart. Ask any customer that uses the being/finish scripts what they do with them, they will all be different. > 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. > And how are you going to support my scripts above? I have a new requirement that isn't a solution but would take a few lines in a shell script. > My .02. > -- Thanks... Mike Dotson Area Technical Engineer - ACS West Phone: (503) 343-5157 Mike.Dotson at Sun.Com
