[Ovirt-devel] [PATCH server] controller service layer refactoring for pools.

David Lutterkort lutter at redhat.com
Wed Apr 29 22:52:01 UTC 2009


On Wed, 2009-04-29 at 16:50 -0400, Scott Seago wrote:
> David Lutterkort wrote:
> > On Tue, 2009-04-28 at 22:10 +0000, Scott Seago wrote:
> >   
> >> This is the second round of controller/service layer refactoring
> >> changes -- in this case for the pool-related controllers (HW, VM, and
> >> Smart pools)
> >>     
> >
> > This looks mostly good, modulo comments below. It would also be good to
> > include rdoc comments in the service modules to document required
> > permissions and instance variables that get set.
> >
> >   
> I'll look over your rdoc bits and then do something similar -- although 
> at this point, with this patch size (and considering vm_service already 
> pushed) that should probably be a follow-on patch.

Agreed.

> > Why the separate method render_show ? I don't think it simplifies things
> > compared to inlining that method.
> >
> >   
> render_show is used in the pool subclasses as well.

Ok .. didn't notice that when I wrote the above.

> Sure. I just fixed it here since it prevented me from testing the pool 
> controller refactoring properly, but I can pull it out assuming git 
> doesn't clobber my commit when I try to split it in two.

Interactive rebase is your friend ;) See [1] for more detailed
instructions on how to split a commit.

> >> +    # from before_filter
> >> +    @pool = HardwarePool.new(pool_hash)
> >> +    @parent = Pool.find(other_args[:parent_id])
> >> +    authorized!(Privilege::MODIFY, at parent)
> >> +
> >> +    alert = "Hardware Pool was successfully created."
> >> +    Pool.transaction do
> >> +      @pool.create_with_parent(@parent)
> >> +      begin
> >> +        if other_args[:resource_type] == "hosts"
> >> +          svc_move_hosts(@pool.id, other_args[:resource_ids].split(","), @pool.id)
> >> +        elsif other_args[:resource_type] == "storage"
> >> +          svc_move_storage(@pool.id, other_args[:resource_ids].split(","), @pool.id)
> >> +        end
> >> +        # wrapped in a transaction, so fail on partial success
> >> +      rescue PartialEuccessError => ex
> >> +        raise ActionError.new("Could not move all hosts or storage to this pool")
> >>     

In rereading this, I just noticed that there's a typo in
'PartialSuccessError'.

> > Why not make throwing PartialSuccessError part of the method's
> > signature ? Does wrapping in an ActionError really buy us anything ?
> >
> >   
> I'm wrapping it since I'm rethrowing it within a transaction -- causing 
> an abort.

My main objection was that by rethrowing a different exception we
obscure the actual failure for the caller and make it harder to create a
precise error message - this would actually all be moot if we made
PartialSuccessError a subclass of ActionError.

> >> +      end
> >> +    end
> >> +    return alert
> >> +  end
> >> +
> >> +  def svc_move_hosts(pool_id, host_ids, target_pool_id)
> >> +    svc_move_items_internal(pool_id, Host, host_ids, target_pool_id)
> >> +  end
> >> +  def svc_move_storage(pool_id, storage_pool_ids, target_pool_id)
> >> +    svc_move_items_internal(pool_id, StoragePool, storage_pool_ids, target_pool_id)
> >> +  end
> >> +  def svc_move_items_internal(pool_id, item_class, resource_ids, target_pool_id)
> >> +    # from before_filter
> >> +    @pool = HardwarePool.find(pool_id)
> >> +    target_pool = Pool.find(target_pool_id)
> >> +    authorized!(Privilege::MODIFY,target_pool)
> >> +    authorized!(Privilege::MODIFY, at pool) unless @pool == target_pool
> >>     
> >
> > Does it even make sense to do anything if @pool == target_pool ? We
> > should just bail.
> >
> >   
> We shouldn't bail, since for the "move hosts _to_ this pool" operation 
> they will be the same -- the unless clause keeps us from making the 
> check twice. For the "move hosts _to another_ pool" case the two will be 
> different.

Ahh, ok, that makes sense (though the unless clause is unnecessary with
the changes to set_perms that are also in the patch)

David

[1] http://book.git-scm.com/4_interactive_rebasing.html





More information about the ovirt-devel mailing list