Hi Glenn, Thanks for all the responses. I got a few comments to your responses.
Glenn Lagasse wrote: > > >> - 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. > > IMO, if a value will only be used by 1 finalizer script, it is easiest to pass it in as an argument to the script. If a value is needed by multiple scripts, it is more error-prone to pass it in as arguments to different scripts. It is probably better to define it "somewhere appropriate" in the manifest once, and then, just have the finalizer scripts query it. >> - 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. > When we talk with the IPS group a couple of weeks ago, I believe they said that the functionality is already available in the API level, and we just need to call those or something like that. Since this same functionality is needed by the GUI and Text Installer as well, probably a program/function can be implemented and all the components that needed the info can use that. Then, VMC can take the list of packages specified by the deployer for the VM image, and figure out the needed size for the disk. > > >> - 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). > I just remember one more thing. If we take the approach to accept a pre-built ISO, the VMC project will need to implement the following RFE: http://defect.opensolaris.org/bz/show_bug.cgi?id=6336 Because, currently, the step to populate the image with the list of packages is "built-in" to DC, so, it is always done regardless what's specified in the manifest. Thanks, --Karen
