atom feed23 messages in net.launchpad.lists.openstackRe: [Openstack] [keystone] v3 API dra...
FromSent OnAttachments
Joseph HeckJun 10, 2012 1:57 pm 
Mark NottinghamJun 11, 2012 10:27 pm 
Gabriel HurleyJun 12, 2012 1:23 am 
Mark NottinghamJun 12, 2012 3:10 am 
Joseph HeckJun 12, 2012 9:09 am 
Adam YoungJun 12, 2012 9:21 am 
Jay PipesJun 12, 2012 10:16 am 
Jay PipesJun 12, 2012 10:30 am 
Dolph MathewsJun 12, 2012 12:17 pm 
Michael BartonJun 12, 2012 2:12 pm 
Mark NottinghamJun 12, 2012 7:19 pm 
Gabriel HurleyJun 12, 2012 8:24 pm 
Mark NottinghamJun 12, 2012 8:42 pm 
Christopher B FerrisJun 13, 2012 4:52 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:56 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:29 pm.gif, .gif, .gif
Subject:Re: [Openstack] [keystone] v3 API draft (update and questions to the community)
From:Christopher B Ferris (chri@us.ibm.com)
Date:Jun 13, 2012 4:52:55 am
List:net.launchpad.lists.openstack

+1

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.

We were discussing just that on the docs meeting earlier in the week. Whether it is a formal spec, or just documentation, is certainly open to debate. We may have need of both. This applies across all projects, IMO.

Cheers,

Christopher Ferris IBM Distinguished Engineer, CTO Industry and Cloud Standards Member, IBM Academy of Technology IBM Software Group, Standards Strategy email: chri@us.ibm.com Twitter: christo4ferris phone: +1 508 234 2986

-----openstack-bounces+chrisfer=us.i@lists.launchpad.net wrote: ----- To: "open@lists.launchpad.net" <open@lists.launchpad.net> From: Gabriel Hurley <gabr@nebula.com> Sent by: openstack-bounces+chrisfer=us.i@lists.launchpad.net Date: 06/12/2012 11:28PM Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to the community)

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.

My two cents,

- Gabriel

-----Original Message----- From: openstack-bounces+gabriel.hurley=nebu@lists.launchpad.net [[1]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.

Cheers,

-- Mark Nottingham [2]http://www.mnot.net/

_______________________________________________ Mailing list: [3]https://launchpad.net/~openstack Post to : open@lists.launchpad.net Unsubscribe : [4]https://launchpad.net/~openstack More help : [5]https://help.launchpad.net/ListHelp

_______________________________________________ Mailing list: [6]https://launchpad.net/~openstack Post to : open@lists.launchpad.net Unsubscribe : [7]https://launchpad.net/~openstack More help : [8]https://help.launchpad.net/ListHelp

</gabr@nebula.com>

References

Visible links 1. mailto:openstack- 2. http://www.mnot.net/ 3. https://launchpad.net/~openstack 4. https://launchpad.net/~openstack 5. https://help.launchpad.net/ListHelp 6. https://launchpad.net/~openstack 7. https://launchpad.net/~openstack 8. https://help.launchpad.net/ListHelp

_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : open@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp