Hi Karen, Thanks for the feedback! My responses are below.
* Karen Tung (Karen.Tung at Sun.COM) wrote: > > Glenn Lagasse wrote: > >All, > > > >I've posted the first rev of the design document for the Virtual Machine > >Constructor project at the following location: > > > ><http://www.opensolaris.org/os/project/caiman/VMC> > > > >Please provide any comments you may have by COB Friday, July 31st. If > >you need more time to review the document, please let me know. > > > >Thanks, > > > > Hi Glenn and team, > > Here are my comments on the spec. > > - General comment 1: it would be useful to provide a pointer to the > functional spec from this doc, it can be referenced easily. Agreed. > - General comment 2: the doc just mention the code will integrate > into slim_source gate. It would be useful to document the exact > path. Agreed. > Also, will new directories inside the distro_const directory be > created for all the VMC related code or not? I think there will be a VMC directory. It will help seperate things. > - Components section: It would be useful to list which components > are produced by the VMC project, and which are components that you > use Agreed. > - VMC Manifest: It would be useful to specify whether these are new > tags? Or replacement tags to existing things? and which section in > the DC manifest these tags will appear. Also, what happened to all > the existing content in DC manifests? Additionally, for DC, the > order in which the finalizer scripts are listed is very important. > So, please list the order of the finalizer scripts (new and > existing), and the order in which they will be executed. It would > be much more clear if you can include the manifest the VMC project > will use as reference. Well, we don't have a manifest yet (it's a task to create one). At the moment, it's likely to be very stripped down from the other DC manifests we currently have and consist mostly of just a finalizer section. We can definitely clarify what order the finalizer scripts will be run in. And as for tags, it looks like we may not use tags and just specify values as arguments to the finalizer scripts. > - vm_memory_size and vm_disk_size: the spec says it defaults to AI > client memory/installation size. Does this mean the value for these > 2 things will be calculated dynamically? No. The AI client (though I haven't found it yet) has I believe some idea of what it requires in order to work in terms of client memory. So, for installing the VM we'll set the memory to that required size. After the VM is installed, we'll allow the user to set the memory size of the VM to whatever value he wants to deploy the VM with. The disk size is a different problem. If we were using something like the liveCD that includes the image size we could use that, but we don't. I know there's been discussion about getting IPS to deliver some sort of interface for figuring out how big an installed set of packages is but I don't think there's anything imminent there. For now, the deployer will need to have an idea of how much disk space he needs inside the VM in order to set it. > - The spec says "All VMC finalizer scripts will be implemented using > KSH shell". I think it would be useful to explain why KSH is chosen > over > other languages in the spec. We did, though not in the best place. It's in the phase section. We'll move it closer to where it's discussed. > - prepare_ai_iso.ksh "overview" section, first sentence: It would be > more clear to specify exactly what's the "proposed direction of the > bootable AI client project". Sure, but the functional spec for that project isn't complete yet. Once it is, we can adjust. > - prepare_ai_iso.ksh "input" section: When I first read "input", I > thought these are arguments that get passed into the finalizer > script. > After a while, I realized these 2 input values will be retrieved > from tags in the DC manifest. It would be useful to talk about > that, > and also say exactly which tag from the DC manifest it will use to > get the values. This is going to change likely. I think we're going to implement the former (you're first thought). > - create_vm.ksh "input" section: since the "prepare_ai_iso.ksh" > script must modify the ISO to make it work with the bootable AI > project, I don't think you the <full path to bootable ai iso> tag as > well as that "if-then-else" statement is useful. Instead, you need > to specify how this will > coordinate with the parepare_ai_iso.ksh script to make sure that you > can figure out where's the prepared ISO. Yes, this is another piece of the design that is under discussion (to build AI media as part of VMC or not). > - create_vm.ksh "Description" section: why "If an error is detected > a meaningful error message will be written to the DC log"? Why not > just display all output and error? DC will log them appropriately. > Is there a lot of output from those VM commands? We are going to display all output and an error message. > - install_vm.ksh "Overview" section: I assume the bootable AI image > will have SSH disabled. In order to allow monitoring of the install > log via ssh, we need to enable SSH in the bootable AI image some > how, not just configure the VM to allow SSH. Correct. > - post_install_vm_config.ksh, "overview" section: I think the RAM > size specified in the manifest is used in creating the VM, why do we > need to reset it here? Because the RAM requirements for installing the VM are going to be different from what the deployer wants to deploy the VM with. The RAM requirements for installing the VM should be only what the AI client requires to do an installation. Which is probably less than what the deployer wants the images to go out with (and potentially not available on the machine he's running DC on). > - export_vm.ksh, exported VM in supported formats. You didn't > specify which format. Is it intentional that you want to keep it > vague like that? > In the diagram, you did say OVF. > > - Diagram: step 2: I thought AI client ISO is always provided. If > it is not provided, the design doc didn't discuss how it will be > generated. Yep, we need to update this based on the outcome of the ongoing discussion about whether to require an AI client iso in all cases. > What about the other scripts mentioned above? We'll need to update the diagram for them as well. Thanks Karen! -- Glenn
