Hi Glenn, My comments/question on your functional spec. I noted the section and any important text prior to my comments/questions.
Section 1.4.2: > This is not likely to be an issue but > should be noted. The interface needs to remain stable and available. This > project will need to work with the VirtualBox group to ensure that > whatever > interface we use remains stable and available. Seems like we should be more specific here. We actually would need a contract, right? I am not sure this is doable with a project that isn't arc'd but I am concerned about how we keep track of this. Section 1.5: > Sufficient memory to run a VirtualBox guest in addition to the Host OS > o Sufficient disk space to support the building of an AI image as well as > a VM. What is 'sufficient' for these two requirements? Section 5.1: > Currently there is no functional specification for a bootable AI Image. > The expected functionality we'll require for this project from such > a creation is listed below: > - Automatic Target Discovery (TD) of Virtual Disk inside VM > - Automatic Target Instantiation (TI) of discovered Virtual Disk > - Automatic Transfer of bits (TM), either via cpio from the > bootable AI media or via IPS and a network repository > - Install Completion Tasks (ICT) > - Observability of the install process which can be accessed > from outside of the VM so we can detect error conditions, > progress reporting and completion status > - The ability to shut down the VM when finished In looking at these requirements, I don't think they are on the bootable AI image(aka as bootable non-GUI image) specifically. I was thinking that the bootable non-GUI image was only going to provide: -An image that will boot that does not have to contain an installer. Consumers can use this image and add an installer, VM, AI, Text, as they need for their projects. The requirements as you state them are not really provided by a bootable AI image since what you need is a subset of what AI provides today and requires new functionality from the AI client. It will require: -Additions to the AI manifest schema to allow for transfer of bits by cpio. -Additions to the AI 'engine' that will allow for discovery of VM disks(if we don't get this data today). -Additions to the AI 'engine' for observability in to the installation outside the Vbox space. The requirement to shutdown the VM is really an ICT task which you should add as part of your project. I think that it might be better to outline the parts of this project in a way that make it clear what pieces are used for what. For example, you describe use cases with regard to creating the .ovf file, but non to describe the actual process that a user would invoke to 'install' the image that was created. I assume that's what you need the bootable non-GUI image for? Section 6.1.2: > To > introduce this image to the VMC the deployer will modify a tag in > the VMC manifest prior to invoking the DC. I don't understand what the above statement means. So, I want to get some clarification for these user scenarios. It seems to me we have two basic scenarios: 1. The user creates an ovf file using the DC(or something else). The output of their work is the .ovf file. 2. The user gets a bootable image, containing and installer and an .ovf file to use to boot a VM and start an install? Section 6.2.4: Seems like remote observability is a requirement on the AI client project. Have you talked to Sue about this? That's it for now. thanks, sarah > 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! > >
