Hi Glenn,
> 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. > Ok. > >> 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? > AI doesn't do cpio transfer. I believe it only does IPS transfer. So, we need to ensure we add this to the schema if it is a requirement for the installer to do this to generate an .ovf file. > >> -Additions to the AI 'engine' that will allow for discovery of VM >> disks(if we don't get this data today). >> > > Possibly. > > We should look at this to be sure. I don't know exactly what libdiskmgt will find in a VM environment. I assume it will do the right thing, but we should test this. >> -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). > > Ok. >> 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. > > Ok, good point. We would need to add another field to the ai schema to specify this, unless its automatic for every VM install? >> 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. > > I get that now. I was confused for a while. Sorry :-). >> 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. > > Ah... so this is the case where cpio would be used? >> 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? > > I thought, for some reason, we were going to provide a media that would do the 'install' of the ovf file to a VM. I understand now that isn't the case and that a user would bring up a VM and import this file in to that VM. >> 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. > > The observability requirement I see is specifically for the client side of AI. So, in this case, it is outside the bootable AI image itself. What I am getting at is that if we have specific requirements for AI with regard to the VM Constructor project we should enumerate those clearly. > Thanks for the feedback! > > You are welcome. Good work on this! sarah
