Hi Bart, > > Laying down an image would basically be a zfs receive of image prepared > on the server; the majority of software loads are the same and this > would allow installation to proceed at wirespeed w/ no protocol > overheads. > This is something we are planning on for AI(see the requirements doc). But not all of the installations will be done with a zfs send/receive. I do think we need to allow for pkg additions from a repository during the initial AI processing. > If installation time is primary goal, complete prep of image would allow > jumpstart to complete very quickly indeed. > And generally it will complete quickly. I do think we have to allow for user scenarios where customization is required or desired. Customization after the image has been generated.
> Going to the repo to get hundreds of manifests, retrieve thousands of > files, etc, does take time, and is essentially a serial process. > > Agreed. And in general it isn't a recommended way of doing things, but I don't think we should restrict our users to our way. If they want to go to the repo and get the pkgs to customize their systems I think we need to allow for that. > We're doing an automated install... why would a possible extra reboot > matter? > The biggest issue with this is the potential for introducing dependencies in the user scripts on things we don't have in the microroot environment. Certainly we must consider this issue when deciding how we handle post installation configuration. > Particularly given the progress of the fast reboot work, we're talking a > minute > or two. Coding the final customization for a running system should be much > easier as well; the creation of snapshots just before customization scripts > are run will make it much easier to debug them, since iterative approaches > can be used... > Certainly this is all true. And users can do this. And perhaps we provide the post reboot customization hooks which we had been planning as part of Caiman all along. I think though that many customers, based on our requirements gathered, want full install, customization etc.. in one single shot. And to reboot one time. But, I am willing to revisit this as we move forward. > If there's a considerable advantage to running a user-supplied program to > dynamically select a given profile, that doesn't significantly > complicate matters > for us, but there's a lot of customer investment in learning the programming > environment. > yes, there is customer investment. But, many customers use the begin scripting along with the dynamic profile creation mechanism offered my our current Jumpstart. Limiting them seems unnecessary. Learning a scripting or profile language doesn't seem that complicated to me. I think the devil is in the details here. We could make the pre-install script and the profiles very complicated. That isn't our intent. It is our intent not to force the users to have many 'rules' type files, or specific profiles based on every client they have. A dynamic profile is much easier for them in the case where many clients are very similar but just enough different where you want to install them slightly differently. Without dynamic profile creation the users would have to have individual profiles for each client in this case. They could modify these later with postinstall scripts for subsequent customization I suppose. But again, this requires potentially more postinstall scripts. > Some care is needed to insure that the customer's script doesn't require > components that aren't present on the install image. > > Agreed. Completely. This is certainly a requirement we have to maintain while designing this. > Simplicity is probably the key element here; the primary problem w/ > jumpstart > is that it's hard to use. The introduction of JET as an additional > layer sets off > alarm bells. > > It does indeed set off alarm bells. Nothing in what we have proposed so far implies complexity, IMO. I think that JET is an excellent example, one which we are heeding and have researched, of gaps in the initial JS functionality. Also, some of what JET provides implies the customers wanted more than JS provided initially. In particular 3rd party software installations and configuration of said software. And installation at different points in the overall installation processing of this software. We can't solve world hunger. Perhaps we can find the right balance between features and complexity. The requirements I sent, and will be sending an update of, are fairly basic. But, if in your review of them you find things listed that seem unnecessary or out of scope, please comment. Thanks for your time and input. sarah ****
