Heya Sarah, * Sarah Jelinek (Sarah.Jelinek at Sun.COM) wrote: >>> 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.
I thought sure I had read that it did cpio transfer. However after re-reading the design docs, it doesn't. Fortunately, we don't have a requirement on how the bits are installed (whether by cpio transfer or directly from an IPS repo). It just means that the VM we're installing in to will need to be configured with network access to an IPS repository (which shouldn't be hard since we'll need that access on the HOST to generate the bootable AI image in the first place). Or we can enhance the AI client to handle cpio transfers. The former is probably less invasive. >> >>> -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. Well, target discovery is used in the GUI installer and that works in a VM environment so I think we already know that it works. > >>> -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 it would be automatic for every VM install to shutdown upon completion. I can't really think of any reason you'd want to not shutdown when finished (if anyone else can, please let me know). If you don't shutdown, the OVF file isn't created until you do so there's not much point to stopping the process at that point as it were. >>> 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 :-). No worries. It's a lot to digest. :-) > >>> 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? Not necessarily. It just means that we wouldn't generate an AI image before doing the installation. We'd just attempt to use what the user provides. We don't really care what method the AI image uses to transfer bits (modulo making sure we have network access to an IPS repo inside the VM if the image only supports IPS transfer). We just care that it does ;-) > > >>> 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. Yep, exactly. >>> 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. Yep, I'm in touch with Sue to discuss this now. > >> Thanks for the feedback! >> >> > > You are welcome. Good work on this! Thanks! I appreciate that. -- Glenn
