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. Cheers, -- Glenn
