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
