Sarah Jelinek wrote: > Hi Keith, > > Thank you for responding. Stuff inline... > > >> Whoops, forgot to CC to caiman >> >> Keith Mitchell wrote: >>> Hi Sarah, >>> >>> Some comments below. Let me know if I'm misunderstanding some of your >>> comments/questions. >>> >>> Sarah Jelinek 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. >>>> >>>> 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? >>>> >>> "Sufficient" would be: ( Space needed for clean install of image ) + >>> ( Additional Space needed to describe the virtual machine in OVF >>> format). The first section depends on the image being installed; the >>> second would be relatively static, I think, but I don't know what >>> that number would be. > > ok, fair enough for now. As part of this work we would eventually need > to know more specifically what we need to support this. > > >>>> 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. >>>> -Additions to the AI 'engine' that will allow for discovery of VM >>>> disks(if we don't get this data today). >>>> -Additions to the AI 'engine' for observability in to the >>>> installation outside the Vbox space. >>>> >>>> The requirement to shutdown the VM is really an ICT task which you >>>> should add as part of your project. >>> I would not necessarily call this a strict requirement. It could be >>> done via ICT, or it could be done by having VirtualBox send a >>> shutdown signal to the machine, after determining from progress >>> reporting that the installation is complete. > > Ok, fair enough. We have to have VB send the shutdown signal somehow, > right? Is there a way to tell the VB VM to do this via the api you will > be using?
If the API can not support it it would not be difficult to shutdown the system once the install has completed. It could be accomplished a few different ways. - We could, as Sarah point out, have ICT do it. - We could have an SMF service built into the image which could do it. - bug 6556 "AI should provide an option for automatic reboot after an install" could be expanded to, in addition to reboot, provide for shutdown. > >>>> >>>> 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? >>> The .ovf file is the desired outcome. Unless you're referring to the >>> process the user takes to import the .ovf file into one or more >>> virtual machines after completion? > > yes, I was referring to the process the user takes to import the .ovf > file. I think I was confused on what this project intended to produce. > You are only producing the .ovf file, is that correct? The user must > take this file, and import it to their VM if they want to use it? Yes. The output of VMC is an image type, which happens to be an ovf file. The user would then import this file. As Glenn explained his vision to me, this fits the model for what DC currently does in that it produces a single image file. > > >>>> >>>> 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. >>>> >>>> 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. >>>> 2. The user gets a bootable image, containing and installer and an >>>> .ovf file to use to boot a VM and start an install? >>> Case 2 is not one we intend to support. The basic scenario is, user >>> has no "pre-existing" files, so the VMC will create a bootable, >>> installable ISO image, then create a new clean virtual machine image >>> and virtual hard disk. It will mount the new ISO on the virtual >>> machine and start the virtual machine. The VM will automatically >>> install from the ISO file onto the virtual hard disk, and, once that >>> is complete, the VM will shutdown. Once the shutdown is complete, the >>> VMC will export the virtual machine to a .OVF file. >>> >>> The alternate cases that will be supported include: >>> - The user has already (for whatever reason) built the ISO image. In >>> this case, the VMC does not need to build a fresh ISO, it can just >>> use the existing one. >>> - The user has already (for whatever reason) created a VM (with >>> attached hard disk). In this case, the VMC does not need to create a >>> new one - it will use the existing one as specified. >>> - The user has both an ISO and a VM already available. Combination of >>> the above 2 steps. > > I see, thanks for the clarification. > > thanks, > sarah > ***** > > >>>> >>>> Section 6.2.4: >>>> Seems like remote observability is a requirement on the AI client >>>> project. Have you talked to Sue about this? >>>> >>>> >>>> That's it for now. >>>> >>>> thanks, >>>> sarah >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Hi All, >>>>> >>>>> I've uploaded the functional specification for this project to be >>>>> reviewed at: >>>>> >>>>> http://opensolaris.org/os/project/caiman/VMC >>>>> >>>>> For anyone who doesn't know, the VM Constructor project is intended to >>>>> enhance the distribution constructor to allow it to create >>>>> preconfigured >>>>> and preinstalled virtual machines which can be used by VirtualBox (and >>>>> any other hypervisors that support and can consume OVF images). >>>>> >>>>> Please direct any feedback to this alias/thread. >>>>> >>>>> Thanks! >>>>> >>>> >>>> _______________________________________________ >>>> 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
