From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Veillard Subject: Re: Re: Re: [RFC] Xend XML-RPC Refactoring Date: Sun, 12 Mar 2006 16:49:07 -0500 Message-ID: <20060312214907.GH22089@redhat.com> References: <440E204B.1070402@us.ibm.com> <20060311205510.GH13877@leeni.uk.xensource.com> <20060311213657.GM346@redhat.com> <20060311222053.GA5963@leeni.uk.xensource.com> <20060312095701.GC22089@redhat.com> <20060312182940.GG22089@redhat.com> Reply-To: veillard@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Anthony Liguori Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/