No comments at all on this??

On Wed, May 09, 2012 at 09:35:29AM -0500, Adam Litke wrote:
> I would like to discuss a problem that is going to affect VM creation in the 
> new
> REST API.  This topic has come up previously and I want to revive that
> discussion because it is blocking a proper implementation of VM.create().
> 
> Consider a RESTful VM creation sequence:
>   POST /api/vms/define - Define a new VM in the system
>   POST /api/vms/<id>/disks/add - Add a new disk to the VM
>   POST /api/vms/<id>/cdroms/add - Add a cdrom
>   POST /api/vms/<id>/nics/add - Add a NIC
>   PUT /api/vms/<id> - Change boot sequence
>   POST /api/vms/<id>/start - Boot the VM
> 
> Unfortunately this is not possible today with vdsm because a VM must be
> fully-specified at the time of creation and it will be started immediately.
> 
> As I see it there are two ways forward:
> 
> 1.) Deviate from a REST model and require a VM resource definition to include
> all sub-collections inline.
> -- or --
> 2.) Support storage of vm definitions so that powered off VMs can be 
> manipulated
> by the API.
> 
> My preference would be #2 because: it makes the API more closely follow 
> RESTful
> principles, it maintains parity with the cluster-level VM manipulation API, 
> and
> it makes the API easier to use in standalone mode.
> 
> Here is my idea on how this could be accomplished without committing to 
> stateful
> host storage.  In the past we have discussed adding an API for storing 
> arbitrary
> metadata blobs on the master storage domain.  If this API were available we
> could use it to create a transient VM "construction site".  Let's walk through
> the above RESTful sequence again and see how my idea would work in practice:
> 
> * POST /api/vms/define - Define a new VM in the system
> A new VM definition would be written to the master storage domain metadata 
> area.
> 
> * GET /api/vms/<new-uuid>
> The normal 'list' API is consulted as usual.  The VM will not be found there
> because it is not yet created.  Next, the metadata area is consulted.  The VM 
> is
> found there and will be returned.  The VM state will be 'New'.
> 
> * POST /api/vms/<id>/disks/add - Add a new disk to the VM
> For 'New' VMs, this will update the VM metadata blob with the new disk
> information.  Otherwise, this will call the hotplugDisk API.
> 
> * POST /api/vms/<id>/cdroms/add - Add a cdrom
> For 'New' VMs, this will update the VM metadata blob with the new cdrom
> information.  If we want to support hotplugged CDROMs we can call that API
> later.
> 
> * POST /api/vms/<id>/nics/add - Add a NIC
> For 'New' VMs, this will update the VM metadata blob with the new nic
> information.  Otherwise it triggers the hotplugNic API.
> 
> * PUT /api/vms/<id> - Change boot sequence
> Only valid for 'New' VMs.  Updates the metadata blob according to the 
> parameters
> specified.
> 
> * POST /api/vms/<id>/start - Boot the VM
> Load the metadata from the master storage domain metadata area.  Call the
> VM.create() API.  Remove the metadata from the master storage domain.
> 
> VDSM will automatically purge old metadata from the master storage domain.  
> This
> could be done any time a domain is: attached as master, deactivated, and
> periodically.
> 
> How does this idea sound?  I am certain that it can be improved by those of 
> you
> with more experience and different viewpoints.  Thoughts and comments?
> 
> -- 
> Adam Litke <a...@us.ibm.com>
> IBM Linux Technology Center
> 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel

-- 
Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to