Glenn Lagasse wrote: > Hi Karen, > > * Karen Tung (Karen.Tung at Sun.COM) wrote: >> Glenn Lagasse wrote: >>> Hi All, >>> >>> I've uploaded the functional specification for this project to be >>> reviewed at: >>> >>> http://opensolaris.org/os/project/caiman/VMC >>> >>> For anyone who doesn't know, the VM Constructor project is intended to >>> enhance the distribution constructor to allow it to create preconfigured >>> and preinstalled virtual machines which can be used by VirtualBox (and >>> any other hypervisors that support and can consume OVF images). >>> >>> Please direct any feedback to this alias/thread. >>> >>> Thanks! >>> >>> >> Section 1.6: >> Why specially define the term "deployer" in this case? Wouldn't "DC >> user" work? From the DC users' point of view, it's just another image >> type that they can create. > > DC user could work, I guess I just 'up-leveled' the definition. The > deployer is of course a DC user. To me, DC user didn't quite convey the > overall intent (which is to create images to deploy). I suppose all DC > users create images to deploy in some fashion so perhaps it's not > important. > >> Section 3.0: >> You mentioned that the user can manifest is for DC to create a bootable >> AI image and create and configure >> the VM. I think the part about creating a bootable AI image is an >> implementation detail, which they >> shouldn't have to know about. >> From the user's point of view, all they care is that they can specify a >> list of packages, and perhaps a few >> attributes of the resulting VM, and DC will do all the work to put those >> packages into this VM. > > Yeah, I think I agree with this. I'll change it. > >> Section 5.1: >> After the ICTs, would there be a need to reboot the VM somehow so some >> of the first boot setups >> are run? That way, when people boot up their VM image, they don't have >> to waste the time >> to wait. > > I don't believe that the time is that significant (though I haven't > wall-clocked it). We could reboot after installation but then we don't > have a clean method of shutting down the system. How do you know when > the system is fully-booted and it's safe to shut down from outside the > VM? I don't think optimizing this aspect is terribly important.
Depending on what happens with the system configuration/eSMF project we might need to consider doing reboot configuration. It's not clear yet. I am following that project. > >> Section 6.2.4: >> Besides those failures you described, what about any error from booting >> the image, and starting >> the installation? > > Failures such as those will be handled entirely depending on what > support the bootable AI image has for reporting these errors to some > remote process (in our case DC). Since that isn't designed yet, I don't > know how it will work. If nothing else, we'll have a timeout for the VM > to be installed in and generate a failure if the VM hasn't shutdown > within that timeframe. I'm pretty certain we can do better than that > with the bootable AI image design. > > Thanks! >
