Hi Sarah, 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. > Completely agree. And actually, I should amend the above to be (Space to run DC) + (Space needed for clean OSol install) + (Space to describe VM) + (Space for final OVF file). The DC recommendation is currently set as 8 GB. A clean OSol install from the LiveCD takes about 3 GB. The space to describe the VM is small (I just checked by creating a new, empty VM with no HD - it was in the kb range). The final OVF file should be smaller than the installed VM, since the OVF is compressed. In grand total minimum space requirement should be around or under 12 GB - depending on how flexible some of those numbers are, and again, how many packages the user installs. It also depends on how much of the recommended minimum for DC could overlap with some of our requirements here - I don't know how the DC number was derived.
I didn't initially address the RAM question - since this isn't a GUI install, I would ball park at 1.5 GB being the minimum; with 2+ being preferred. > >>>> 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? Yes. > >>>> >>>> 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? Currently, the desired final outcome is a .ovf file. Importing the file elsewhere depends on the host Operating System, and (potentially) the VM software being run. -Keith > > >>>> >>>> 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 >>> >
