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. > 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! -- Glenn
