|Joseph Heck||Jun 10, 2012 1:57 pm|
|Mark Nottingham||Jun 11, 2012 10:27 pm|
|Gabriel Hurley||Jun 12, 2012 1:23 am|
|Mark Nottingham||Jun 12, 2012 3:10 am|
|Joseph Heck||Jun 12, 2012 9:09 am|
|Adam Young||Jun 12, 2012 9:21 am|
|Jay Pipes||Jun 12, 2012 10:16 am|
|Jay Pipes||Jun 12, 2012 10:30 am|
|Dolph Mathews||Jun 12, 2012 12:17 pm|
|Michael Barton||Jun 12, 2012 2:12 pm|
|Mark Nottingham||Jun 12, 2012 7:19 pm|
|Gabriel Hurley||Jun 12, 2012 8:24 pm|
|Mark Nottingham||Jun 12, 2012 8:42 pm|
|Christopher B Ferris||Jun 13, 2012 4:52 am|
|Gabriel Hurley||Jun 13, 2012 2:32 pm|
|Nguyen, Liem Manh||Jun 14, 2012 9:08 am|
|Mark Nottingham||Jun 14, 2012 5:20 pm|
|Doug Davis||Jun 15, 2012 5:35 am|
|Christopher B Ferris||Jun 15, 2012 6:56 am|
|Nguyen, Liem Manh||Jun 15, 2012 9:50 am|
|Jorge Williams||Jun 15, 2012 11:48 am|
|Jorge Williams||Jun 15, 2012 11:50 am|
|Hua ZZ Zhang||Jun 17, 2012 10:29 pm||.gif, .gif, .gif|
|Subject:||Re: [Openstack] [keystone] v3 API draft (update and questions to the community)|
|From:||Nguyen, Liem Manh (liem...@hp.com)|
|Date:||Jun 14, 2012 9:08:03 am|
IMHO, a well-documented WADL + XSD would say a thousand words (maybe more)...
And can serve as a basis for automated testing as well. I understand that the
v3 API draft is perhaps not at that stage yet; but, would like to see a WADL +
XSD set as soon as the concepts are solidified.
[mailto:openstack-bounces+liem_m_nguyen=hp....@lists.launchpad.net] On Behalf Of
Mark Nottingham Sent: Tuesday, June 12, 2012 8:43 PM To: Gabriel Hurley Cc: open...@lists.launchpad.net Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to the
On 13/06/2012, at 1:24 PM, Gabriel Hurley wrote:
Totally agree with all of Jay's points, and I also couldn't agree more with Mark
on the importance of being crystal clear, and not operating on just a "common
understanding" which is quickly misunderstood or forgotten.
Ideally I'd like to see an OpenStack API feature contract of some sort...
essentially a document describing the FULL list of features, how those
parameters are controlled and how they would interact, and what a project should
do if they do not implement an API feature (hopefully only for technical reasons
such as Keystone paging with LDAP or swift with complex DB-esque operations).
This isn't saying we should have a unified API spec, I'm talking solely about a
contract for the features all APIs should strive to support.
This would be a big project, but everyone would then have a common agreement
about what the user experience of interacting with OpenStack should be. The
project APIs as they stand are siloed and stunningly inconsistent, and I'd love
to work toward fixing that.
One of my other projects is to rewrite the API as a proper specification (in a
style similar to an Internet-Draft, not that we'd necessarily publish it as
I should have something to show soon; if you're interested in helping out,
that'd be great.
My two cents,
-----Original Message----- From: openstack-bounces+gabriel.hurley=nebu...@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebu...@lists.launchpad.net] On Behalf Of Mark Nottingham Sent: Tuesday, June 12, 2012 7:20 PM To: Jay Pipes Cc: open...@lists.launchpad.net Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to the community)
On 13/06/2012, at 3:31 AM, Jay Pipes wrote:
This isn't necessarily true. Nova's compute layer goes through a number of
steps to ensure a semi-transactional nature to certain operations like resizing. Certain times a query needs to indicate that it intends to make a reservation of resources (see quota/reservation system now .. this is the SELECT FOR UPDATE paradigm) and other times, the query doesn't care about such things. In the latter case, there aren't expectations that the list returned is 100% accurate according to the state of the database at a particular timestamp of when the transaction occurred. In this case, filters and optimistic pagination works perfectly fine, IMHO.
That might work, but we need to be crystal-clear about the semantics of what we're giving back; having it understood between OpenStack projects isn't good enough.
I.e., we're not building the APIs just for Horizon; they're for lots of folks,
and subtle semantics -- even when well-documented, much less when they're not -- are often misunderstood.
-- Mark Nottingham http://www.mnot.net/
-- Mark Nottingham http://www.mnot.net/
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : open...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp