Hi Glenn, > Hey Alok, > > * Alok Aggarwal (Alok.Aggarwal at Sun.COM) wrote: > >> On Mon, 27 Jul 2009, Glenn Lagasse wrote: >> >> >>> During my 10 minute :-) presentation on thursday, Clay and Sarah both >>> brought up an issue with one of the design points for Virtual Machine >>> Constructor. Specifically the plan to allow a user to construct a >>> bootable AI media during Virtual Machine Construction. Their argument >>> to not doing this is maintainability, supportability and easing the test >>> matrix. They proposed not allowing the creation of bootable AI media >>> during Virtual Machine Construction and only allowing the user to >>> specify a path to a pre-constructed bootable AI piece of media. >>> >>> I like this approach. This clearly seperates the payload construction >>> (bootable AI media) from what is required to construct a Virtual >>> Machine. Users will need to construct a bootable AI media (or use the >>> default bootable AI media image) before they can run the Virtual Machine >>> Constructor. The VMC will take this media and de-construct it so that >>> it can be used to install the VM the user wants to create. >>> Additionally, if the user specifies an AI client manifest in the VMC DC >>> manifest then we'll replace the default AI client manifest on the >>> bootable AI media (also specified by the user) during the >>> de-construction phase[1] of the bootable AI media. >>> >>> Does anyone have any thoughts on this in addition to what was brought up >>> on thursday? Does anyone think it's a bad idea? >>> >> I think a two-step scheme as this one has the potential >> to confuse users. >> >> The target audience for the VMC work seems to be the >> cloud/appliance settings where machines need to be provisioned >> quickly. Why do we want to expose the (implementation) >> detail of using an AI image to achieve that provisioning >> in the first place? >> > > 1) Supportability > > The VM Construction project is going to use the AI client to perform > it's installations. So, we're constrained in that we can only consume > what the AI client can provide. I think seperating this out is more > understandable to users. It makes the VM construction process more > about 'just what's needed to configure a VM's settings' and less about > how to deploy inside a VM. > > 1) Ease of maintenance > > If we construct an AI client image as part of VM construction then we > either duplicate the AI client image construction in the VMC DC Manifest > or figure out a way to call DC twice in the same context (once to > construct an AI image and then again to do the VM construction). > > Duplicating the AI DC manifest in the VMC DC manifest doesn't sound > great to me. I think the story of: Create an AI client image to > whatever specifications you want (within the AI client constraints) then > supply that image to VMC isn't that untenable for users. And, ideally > if they download the default AI image and supply that to VMC we'll > deconstruct it and put a different AI client manifest on it for them and > they won't have to build a thing. They'll create a custom AI client > manifest, a VMC DC manifest and then run DC. > >
I think that it would be possible, in the future, to perhaps replace the AI image with say a text installer image. In that sense, having the user provide the image and having use it, and then deploy the installer to install the VM is more flexible by separating out the payload(installer). Right now we are constrained to the AI image, but nothing I can see means that this will always be true. The support issues of us building our own AI images, or any installer image, to me seems a high cost for what we can provide using an existing image. The user only knows they have to provide an installer, right? They won't know we are de-constructing it and putting in a different menu.lst, etc... We can hide those details from the users. sarah ******
