Re: [Xen-devel] Re: Re: [RFC] Xend XML-RPC Refactoring

[Daniel Veillard <veillard@xxxxxxxxxx>]

On Sun, Mar 12, 2006 at 02:28:24PM -0600, Anthony Liguori wrote:
> Does this sound sane?  This has been my long term vision for how
> things ought to work.  One could actually implement xend-remote pretty
> easily right now.  Of course, I'm flexible and open to alternatives.

  It's Sunday, it's late, I think I understand your viewpoint (especially
after the exchange on IRC). Still it decouples completely authentication
and right checking from the API. And I feel like we are trying to create
a solution which may not be adequate.
  I really feel of rights over Xen operations to best reflected by
tokens or capacities to use the old term. For me to create a domain
on a node then you need the capacity for that node, as a result you
get a capacity for that domain. Now once you have the capacity for the
domain you can pause/unpause/save or reduce its resource allocations.
To list domains you don't need a capacity. To shudown/destroy a domain
you need the node or domain capacity. To migrate a domain to a new node
you need both the domain and remote node capacities, etc ...
  So I really think of the authentication and security checkings in 
a very different model a priori than what you are suggesting, maybe 
the model I would like to see is just too complex, or doesn't fit
the tools available. That's probably why using a separate controller
which is unlikely to understand the API and auth at the pure connection
layer feels strange too me. I find that way too coarse, while at the
same time probably expensive to run.
  I certainly need to think more about this, other should probably
tell me how wrong I am too, that should not block going forward with
the current plan anyway :-)

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel