Hi Sarah, I see Keith has responded to some of your questions. I'll add my .02.
* Sarah Jelinek (Sarah.Jelinek at Sun.COM) wrote: > 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. Well, that's how we would do it in the past. I don't know how we'll do it in this case since it's not ARC'ed and I doubt it ever will be. Clearly we'll need to be in contact with that team and have *something* in place. > 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? Keith answered this nicely. > 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. Why? I thought the AI image already did this? > -Additions to the AI 'engine' that will allow for discovery of VM > disks(if we don't get this data today). Possibly. > -Additions to the AI 'engine' for observability in to the installation > outside the Vbox space. Definitely. My vision for the bootable AI image was to enhance what is already there. That seemed the easiest course to me. Basically AI without the webserver portion and a few additional pieces (the observability being the largest I think). > The requirement to shutdown the VM is really an ICT task which you > should add as part of your project. I disagree. The AI iso already provides for rebooting the AI client, enhancing it to support shutdown should be trivial. > 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? Precisely. The creation of the bootable AI image is actually transparent to the user. Ideally they won't even know what exactly is being done, they'll just specify a package list and then DC will do the rest. The same for the installation phase. The fact that the install is happening from a bootable AI image should be nothing more than an implementation detail to the user constructing the image. > 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. It means that the deployer will change an xml tag in the VMC manifest to provide the location of a pre-constructed bootable AI image that they've already built (for whatever reason). This would be in lieu of supplying a list of packages they want the resultant OVF image to contain. > 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. Essentially. To the user running DC, he's goal is to ultimately create an OVF file that he can distribute to other users. The fact that we're going to create a bootable AI iso and use that to actually create the OVF is an implementation detail. Unless the user already has a bootable AI iso that he wants to use. Regardless, the bootable AI iso is essentially thrown away once the OVF file is complete and the user won't even know it existed. > 2. The user gets a bootable image, containing and installer and an .ovf > file to use to boot a VM and start an install? Which user are you referring to here? The user creating the OVF file that they want to distribute to other users? Or the user who is trying to user an OVF file that someone else created? > Section 6.2.4: > Seems like remote observability is a requirement on the AI client > project. Have you talked to Sue about this? I have not, I wasn't sure where the 'bootable AI image' was going to end up other than the one conversation you and I had where you said it was going to be covered under the Grand Unified Redesign work. Thanks for the feedback! -- Glenn
