Hey Sarah, * Sarah Jelinek (Sarah.Jelinek at Sun.COM) wrote: > 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.
I agree. We're using AI now, that doesn't preclude us from using something else down the road. > 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. Absolutely. All the user knows is that he has to provide a bootable AI image (or just AI image once Alok's work is done) and we'll do the rest. At most, they'll have to supply the image and a customized AI client manifest if they don't want to use the one on the image they're using but that's all they'll see of the process. Thanks Sarah, -- Glenn
