Hi Bart,
> Ok.... zfs receive + fixup image repo pointers + pkg -R ... <pkglist> That would work. >>> 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. >> > Running arbitrary commands in a installation context? If you > constrain it to IPS pkg additions, OK; we will know that > those work. Add misc sv4r pkgs w/ usual postinstall crap??? Does > installer image contain patchadd? It currently does contain patchadd. JS allows for adding patches as part of the installation process. Obviously with IPS don't need to worry about adding patches. We are not proposing SVR4 package support in postinstall. We are going to utilize the new technologies available to us which should reduce the number of issues we see with the tools that are broken today, such as patching. > Note also that > if you allow users to execute scripts in installation context, that > context becomes a yet another committed set of APIs and > a programming environment. Yep, that's understood. > Most of our admin tools don't work on alternate roots, forcing > customers to do customizations > w/ scripts that edit config files directly... > We have the same issues with live upgrade if users run postinstall scripts on the alternate roots(this would have to be done manually for the current lu). I think that alternate roots are a reality, every upgrade we will be doing for Indiana requires an alternate root. If we don't allow alternate root customizations then every snap upgrade requires the users to reboot, run configuration stuff and reboot again. Alternate roots are even more important in the way forward with Indiana. Everything we will do will provide an alternate root for users to boot back to. If we have deficiencies in our admin tools with regard to alternate roots then we need to look at those tools, understand why the issues are present and see if we can modify the tools to operate on alternate roots. In this way we will better understand what limitations we need to consider when allowing operations on alternate roots. > If you carefully scope a way of dynamically selecting profiles, and > hold off w/ user-programmed customizations until the > system reboot things will be much simpler, and you're not disabling > any functionality. >>> 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. > Why do they want this? Because that's the way it works now? That's > not a requirement, that's a preference. We do tons of processing on > first boot; installing additional software is no different. Indeed we do lots of processing on first boot. That processing doesn't require a second reboot. Installing new software may require a reboot. What would be interesting would be to get data on is how much and what types of 3rd party software require reboot after installation. I think looking at this requirement in terms of what the needs really are is something we can do. > >>> 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 differ >> 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. > In general, I find the more ways software provides to perform a > function, the more bugs crawl out.... > I don't think there is anything in what we are proposing that implies we are building in complexity. > Designing the new AI to include all previous modes of operations plus > all new ones is just asking for problems. I am not sure why you believe we are designing in all the previous modes plus all new ones. This discussion on AI requirements certainly has been in depth with a lot of different ideas bounced around. I re-read the requirements document this morning in an effort to see where it might give the impression we plan to provide old + new modes of operations. I don't see that the requirements imply this at all. We haven't done the design yet and we don't even have the feature set laid out. We have requirements that we believe are critical to the success of AI. The support we are indicating we will provide for say pre and post installation configuration support only says: -Will provide an interface to allow for pre and post installation/upgrade customization. It doesn't imply how we plan to do this. Or what features we can or will allow via customization. We are in agreement on the basic principles for AI. We are working our way through how best to provide what our enterprise customers need along with the direction we want to move toward with Indiana. Regards, sarah
