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.
>> 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.
>>
>> 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?
>>
>> 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.
>>
>> 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
>
