atom feed23 messages in net.launchpad.lists.openstack[Openstack] [keystone] v3 API draft (...
FromSent OnAttachments
Joseph HeckJun 10, 2012 1:58 pm 
Mark NottinghamJun 11, 2012 10:27 pm 
Gabriel HurleyJun 12, 2012 1:24 am 
Mark NottinghamJun 12, 2012 3:11 am 
Joseph HeckJun 12, 2012 9:10 am 
Adam YoungJun 12, 2012 9:21 am 
Jay PipesJun 12, 2012 10:16 am 
Jay PipesJun 12, 2012 10:31 am 
Dolph MathewsJun 12, 2012 12:17 pm 
Michael BartonJun 12, 2012 2:13 pm 
Mark NottinghamJun 12, 2012 7:19 pm 
Gabriel HurleyJun 12, 2012 8:24 pm 
Mark NottinghamJun 12, 2012 8:43 pm 
Christopher B FerrisJun 13, 2012 4:53 am 
Gabriel HurleyJun 13, 2012 2:32 pm 
Nguyen, Liem ManhJun 14, 2012 9:08 am 
Mark NottinghamJun 14, 2012 5:20 pm 
Doug DavisJun 15, 2012 5:35 am 
Christopher B FerrisJun 15, 2012 6:57 am 
Nguyen, Liem ManhJun 15, 2012 9:50 am 
Jorge WilliamsJun 15, 2012 11:48 am 
Jorge WilliamsJun 15, 2012 11:50 am 
Hua ZZ ZhangJun 17, 2012 10:30 pm.gif, .gif, .gif
Subject:[Openstack] [keystone] v3 API draft (update and questions to the community)
From:Joseph Heck (
Date:Jun 10, 2012 1:58:12 pm

First a thank you to everyone who's swung by to read (and some comment) on the
V3 draft at
It's been immensely useful.

To clear up a bit of confusion I caused (sorry Jay!) - there were *no* example
responses included in the document, although some of the pieces certainly looked
like they might be. I put in placeholders for example responses to be added to
make it more explicit, and cleaned up my formatting so that I was consistent
(and hopefully through that, more clear)

This morning/afternoon I went through and tried to provide answers and feedback
to most of the outstanding comments - the folks who commented will see the
results through the Google doc responses as they have notifications defined. I
made a few changes to the draft - in particular, identifing what the "primary
key" in the resource attributes would/should be from a REST perspective, and
crossing out or adding a few attributes here and there based on feedback. I also
tried to make some spelling fixes where I missed earlier.

I've also added an open points discussion near the top of the document, and I'd
like to raise a few of those issues here on the mailing list.

First - what's the current thought of support for PATCH vs PUT in updating REST
resources? Are there any issues with clients being able to use a PATCH verb?
It's not something I'm super familiar with, so I'm looking for feedback from the
community here. Ideally, I'd like to support the semantics of the PATCH HTTP
verb, and possibly just assert no support for the PUT verb to be clear about
intended functionality. Is that going to throw anyone for a loop?

Second - filtering/searching for resources. The draft includes a section
labelled "Query By Name", which is probably mis-labelled, as it's intended to
cover the general idea of passing in query parameters to general listing
resource endpoints to filter the result set. The API endpoints across all the
resources are defined as plurals, with the idea that specificity comes later in
the URI (for referencing a single resource), or that we could add on these query
parameters to restrict/filter by resource type.

Would it be better to make each of the query parameters explicit in the API
beyond the pagination?

Third - there's a general workflow question about how to go from "username +
password" to a token scoped to a specific tenant. There are a few suggestions

1) make a default tenant concept on a user, and when the user authenticates and
gets a token, it's initially scoped to that specific tenant *unless* the
authentication request also explicitly passed in an alternative tenant_id.

1a) The user could then look up any additional tenant_id from the
/users/{userid}/tenants resource path.

1b) a variation of this could be to include a list of all tenants the user is
associated with in the token resource when it's returned, with the token scoped
by default to whatever is set in the user's "default tenant" attribute.

2) when any authentication that is just handed in a username+password and no
tenent_id, hand back a list of tokens, all authenticated for the user.

Fourth - there's an outstanding suggestion that the token resource, in
particular, may be much better suited to including whole resources back, instead
of resource IDs or atom link references to those resources. That's generally how
/token is behaving in the v2 API, and I'm leaning towards making that explicit
in the V3 API as well. Right now the APi defines only that the ID's will be
returned, not representations of the whole resource.

Thoughts? Feedback?