[Ovirt-devel] [PATCH server] First attempt at refactoring the vm_controller using the service layer.
Ian Main
imain at redhat.com
Mon Apr 20 22:13:47 UTC 2009
On Mon, 20 Apr 2009 15:13:13 +0000
Scott Seago <sseago at redhat.com> wrote:
> This code is based on David Lutterkort's proposal outlined in
> https://www.redhat.com/archives/ovirt-devel/2009-April/msg00086.html
[SNIP]
> + def svc_create(vm_hash, start_now)
> + # from before_filter
> + vm_hash[:state] = Vm::STATE_PENDING
> + @vm = Vm.new(params[:vm])
> + @perm_obj = @vm.vm_resource_pool
> + @current_pool_id=@perm_obj.id
> + authorized!(Privilege::MODIFY)
> +
> + alert = "VM was successfully created."
> + Vm.transaction do
> + @vm.save!
> + vm_provision
> + @task = VmTask.new({ :user => @user,
> + :task_target => @vm,
> + :action => VmTask::ACTION_CREATE_VM,
> + :state => Task::STATE_QUEUED})
> + @task.save!
> + if start_now
> + if @vm.get_action_list.include?(VmTask::ACTION_START_VM)
> + @task = VmTask.new({ :user => @user,
> + :task_target => @vm,
> + :action => VmTask::ACTION_START_VM,
> + :state => Task::STATE_QUEUED})
> + @task.save!
I can see this is a bit odd.. if we're calling this from QMF then
there's going to be issues here.. In the current API I don't have
create VM returning a task, which is kind of beside the point, but if
it did then we would have to have a QMF object of this task figured
out when the command returned (there are other APIs that do return
tasks like start_vm). I'm not entirely sure how that would work using
this API right now.. we'd have to somehow figure out which task it was
that was put in the DB.. I wonder if there is a better way to approach
this?
I'm not going to argue this hard here because I know this is a first cut
and just a refactoring but I do think there should be no tasks
associated with creating a VM definition for the API. I think we've
talked about this before.. not a big deal, just wanted to bring it up
for future reference :).
Ian
More information about the ovirt-devel
mailing list