Hi Alok, Comments below...
> 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. I am concerned about each service doing something different based on the type of install media. Why would the services have to know about the install media? Can you give examples of what you are planning with regard to this. Seems to me we have two services as you note: ai client service discovery(which is really manifest discovery). Those things must happen regardless of installation media, correct? The service discovery part doesn't strictly have to run since we haven't setup a service, but making this more generic and utilizing the plans in the transport project for a NULL transport mechanism, it seems to me we could abstract the manifest discovery out in a way that the install media type doesn't matter. My concern about having the services know how they are booted(which is what I assume you are referring to), really makes extending these to add new features possibly less than ideal. Can you clarify you plans in this regard? thanks, sarah
