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. > > Yeah, I know what you mean. It was just odd for me to see that you are specially defining deployer. >> 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. > So, I saw your reply to Keith on this. It's great that you are planning to change the wording. To me, I think it is important to make the distinction about the most-likely path, which is the case where the user would care about their list of packages get into this VM image somehow, verses the "not so common path", where the user would want to specify their own ISO. >> 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. > > So, I understand that there's not a clean method to shut-down the system after the first boot. I couldn't think of an easy way off the top of my head, but it is code, so, we should be able to engineer a way somehow.
IMO, it is important to run through the first boot, so all the initialization stuff is done. Just from personal experience, I think all those SMF initialization stuff take quiet a while at first boot. When a user downloads the VM image to try OpenSolaris, I think it is a bad first impression about OpenSolaris if the boot time is so long. If they don't know that's just the first time, they might conclude from that experience that OpenSolaris has very bad boot time. >> 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. > OK, that sounds fair. Thanks for the good work Glenn. --Karen
