All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Veillard <veillard@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Re: Re: [RFC] Xend XML-RPC Refactoring
Date: Sun, 12 Mar 2006 16:49:07 -0500	[thread overview]
Message-ID: <20060312214907.GH22089@redhat.com> (raw)
In-Reply-To: <pan.2006.03.12.20.28.18.25390@us.ibm.com>

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/

  reply	other threads:[~2006-03-12 21:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-07 23:37 [RFC] Xend XML-RPC Refactoring Ian Pratt
2006-03-08  0:07 ` Anthony Liguori
2006-03-11 20:55   ` Ewan Mellor
2006-03-11 21:36     ` Daniel Veillard
2006-03-11 22:20       ` Ewan Mellor
2006-03-12  1:46         ` Anthony Liguori
2006-03-12  9:27           ` Daniel Veillard
2006-03-12  9:57         ` Daniel Veillard
2006-03-12 17:41           ` Anthony Liguori
2006-03-12 18:29             ` Daniel Veillard
2006-03-12 20:28               ` Anthony Liguori
2006-03-12 21:49                 ` Daniel Veillard [this message]
2006-03-12  1:44     ` Anthony Liguori
2006-03-13 10:30       ` Ewan Mellor
2006-03-14  6:58     ` Anthony Liguori
2006-03-14  8:35       ` Ewan Mellor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060312214907.GH22089@redhat.com \
    --to=veillard@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.