Hey Karen, * Karen Tung (Karen.Tung at Sun.COM) wrote: > 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.
I'm not sure I agree. As it is, every finalizer script is passed in 5 arguments right off the bat whether the script needs them or not (manifest server socket for instance). While I think we will pass some values amongst multiple scripts, I don't think that's necessarily a bad thing. > >>- 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. According to Shawn Walker, this isn't ready yet and isn't likely to be ready for phase 1. Certainly something to keep on the list for subsequent work. > > > >>- 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. That's ugly. Really not something I'd planned for. But I agree, we'll need to do something with it in order to progress. I'm looking it over and will probably have some questions for you about ways to deal with it. Thanks Karen! -- Glenn
