Hi Joe, Glenn answered a number of the question, I'm covering the rest below.
On Thu, 30 Jul 2009, Joseph J. VLcek wrote: > Alok Aggarwal wrote: >> I have posted the first draft of the Bootable AI Image >> functional specification at - >> >> http://www.opensolaris.org/os/project/caiman/Bootable_AI_Image/bootable.ai.spec.txt >> >> >> Please take a look and provide feedback by COB, Thursday >> July 30th. >> >> Thanks, >> Alok >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > Hey Alok, > > Here is my feedback. It is mostly related to the usability of the Bootable AI > Client by VMC. > > Joe > > - - - > > Issue 1: > -------- > > 3.1 Booting an AI image from media > > The VMC project had planned that the default would be > what you list as: > > * Boot from media and invoke AI with a default manifest > > As we discussed it will be possible to modify the image to > set this choice as the default for VMC. > > This task has not been planned as part of the VMC work. The > method to modify the default GRUB selection will be needed. > > Can I ask you to provide a script that will do this that > the VMC can use? Or maybe just helping us with this task... > > Issue 2: > -------- > > 3.3 live-fs-root SMF service refactoring > and > 3.4 auto-installer service refactoring > > Can you please elaborate a bit on what will be done. The live-fs-root service is currently a dumping ground for all sorts of install media and variety of installers (LiveCD, AI, etc). As we add more installers, it will only become more complex and unwieldy. I intend to separate out the logic in that service into two services where each of the service does things a little differently based on the type of install media (network or cdrom/dvd/usb). As for the auto-installer service, it currently performs the dual function of doing service discovery to locate an install manifest and also invoking the auto-install binary. With media based boot, the service discovery doesn't need to run. So, while I'm adding more logic to the auto-installer service, it makes sense to separate out the "locating the manifest" part from "invoking auto-install" part. That would provide for better fault tolerance as well as easier extensibility when derived manifests get added to AI. > Issue 3: > -------- > > Just to clearify: For VMC providing a modified AI manifest would > require that manifest to be built into the image. It will not > be possible for the user to select a manifest at boot time as > control of the boot process will be in a headless virtual machine. > > So the default manifest should be suited to the needs of the VMC > project. The current AI default manifest will meet these needs. > > Issue 4: > -------- > > 5.2 Scenario Two > > This will require the user to select a non-default GRUB option > for x86 boot correct? Correct, but VMC will adjust the grub menu appropriately to make that the default. > The VMC project requires this scenario to not exect any user > input, including selecting of an optional GRUB menu. > > See my comments at "Issue 1" above. > > Issue 5: > -------- > > Status and Observability > > How will the bootable AI client provide progress status and > observability into possible failures, specifically to the VMC? For now, observability would have to be gotten from the install_log. Longer term, the AI Completeness project will address this need. > Issue 6: > -------- > > The VMC requires the Bootable AI Client to "shutdown" the system > after the install, for both successful installation and installs > the produced failures. I think this needs to be filed as an rfe and tracked separately. Thanks for your feedback, Alok
