There is a project page - at the moment, it only contains a draft of the functional spec: http://opensolaris.org/os/project/caiman/VMC/
-Keith Bruce Rothermal wrote: > Is there a project page on opensolaris yet for this project. I would > like to follow it. > > Bruce > > On May 27, 2009, at 3:31 PM, Glenn Lagasse wrote: > >> 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 >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
