Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Dev

Re: WADL [was: v3 API draft (update and questions to the community)]

 

 

OpenStack dev RSS feed   Index | Next | Previous | View Threaded


jorge.williams at rackspace

Jun 15, 2012, 11:48 AM

Post #1 of 3 (226 views)
Permalink
Re: WADL [was: v3 API draft (update and questions to the community)]

Totally agree.

Note that we are using WADL today to create documentation artifacts. So http://api.openstack.org/ is generated from WADLs as are good chunks of the books on http://docs.openstack.org/. We're also using WADL for validation and testing at Rackspace internally, and I'm sure other folks are doing similar things. There are definite practical advantages *today* to having a machine readable artifact. Given that, I don't think Liem's request for a WADL is unreasonable. Sure, WADL has it's problems, and once a viable alternative emerges, I'm sure it will be supported. In fact, having a machine readable artifact has the advantage in this regard, in that it we can auto-convert away from WADL when/if we need to.

-jOrGe W.

On Jun 15, 2012, at 7:35 AM, Doug Davis wrote:


I don't see this as an either-or type of thing.

Totally agree with Mark that the APIs need to be more clearly documented and that should be independent of any kind of IDL (ala WADL) artifact. I say this mainly because I think we always need to have something that's human readable and not machine readable. There will always be semantics that can not be expressed via the machine readable artifacts. Having said that, there are people that like to have IDL-like artifacts for some kind of tooling. So, along with the well-documented APIs should be whatever artifacts that can makes people's lives easier. This means XSD, WASL, WSDL, etc... whatever - pick your favorite.

No matter what artifact you choose to use to guide your coding (even if its just the "well documented human readable API doc"), you're still bound to that particular version of the APIs. Which means a change in the APIs/server-code might break your client. In this respect I don't think WADL or docs are more or less brittle than the other. To me the key aspects are the extensibility points. Once the APIs are deemed 'stable', we just need to make sure that new stuff is backwards compatible which usually means defining and leveraging well placed extensibility points.

thanks
-Doug
______________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug [at] us<mailto:dug [at] us>
The more I'm around some people, the more I like my dog.


Mark Nottingham <mnot [at] mnot<mailto:mnot [at] mnot>>
Sent by: openstack-bounces+dug=us.ibm.com [at] lists<mailto:openstack-bounces+dug=us.ibm.com [at] lists>

06/14/2012 08:20 PM


To
"Nguyen, Liem Manh" <liem_m_nguyen [at] hp<mailto:liem_m_nguyen [at] hp>>
cc
"openstack [at] lists<mailto:openstack [at] lists>" <openstack [at] lists<mailto:openstack [at] lists>>
Subject
[Openstack] WADL [was: v3 API draft (update and questions to the community)]







Hi Liem,

I'm one of the folks who helped Marc get WADL off of the ground. At the time, my use cases were exactly as you describe: documentation (e.g., <https://github.com/mnot/wadl_stylesheets>) and testing.

Even back then, there was a lot of discussion in the community; e.g., see:
http://bitworking.org/news/193/Do-we-need-WADL
http://old.nabble.com/Is-it-a-good-idea-to-make-your-WADL-available--tc6087155r1.html
http://www.25hoursaday.com/weblog/CommentView.aspx?guid=f88dc5a6-0aff-44ca-ba42-38c651612092

I think many of the concerns that were expressed then are still valid -- some even within these limited uses. In no particular order:

* People can and will use WADL to represent a "contract" to a service (really, an IDL), and "bake" client code to a snapshot of it in time. While it's true that the client and server need to have agreement about what goes on the wire and what it means, the assumptions around what guarantees WADL makes are not well-thought-out (in a manner similar to WSDL), making clients generated from it very tightly bound to the snapshot of the server they saw at some point in the past. This, in turn, makes evolution / extension of the API a lot harder than it needs to be.

* WADL's primitives are XML Schema datatypes. This is a horrible match for dynamic languages like Python.

* WADL itself embodies certain patterns of use that tend to show through if you design for it; these may or may not be the best patterns for a particular use case. This is because HTTP and URLs are very flexible things, and it isn't expressive enough to cover all of that space. As a result, you can end up with convoluted APIs that are designed to fit WADL, rather than do the task at hand.

>From what I've seen, many developers in OpenStack are profoundly uninterested in working with WADL. YMMV, but AFAICT this results in the WADL being done by other folks, and not matching the reality of the implementation; not a good situation for anyone.

What we need, I think, is a specification of the API that's precise, unambiguous, and easy to understand and maintain. I personally don't think WADL is up to that task (at least as a primary artefact), so (as I mentioned), I'm going to be proposing another approach.

Cheers,



On 15/06/2012, at 2:08 AM, Nguyen, Liem Manh wrote:

> 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.
>
> Liem
>
> -----Original Message-----
> From: openstack-bounces+liem_m_nguyen=hp.com [at] lists<mailto:openstack-bounces+liem_m_nguyen=hp.com [at] lists> [mailto:openstack-bounces+liem_m_nguyen=hp.com [at] lists] On Behalf Of Mark Nottingham
> Sent: Tuesday, June 12, 2012 8:43 PM
> To: Gabriel Hurley
> Cc: openstack [at] lists<mailto:openstack [at] lists>
> Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to the community)
>
>
> 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.
>
> Absolutely.
>
> 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 one).
>
> I should have something to show soon; if you're interested in helping out, that'd be great.
>
> Cheers,
>
>
>> My two cents,
>>
>> - Gabriel
>>
>>> -----Original Message-----
>>> From: openstack-bounces+gabriel.hurley=nebula.com [at] lists<mailto:openstack-bounces+gabriel.hurley=nebula.com [at] lists>
>>> [mailto:openstack-
>>> bounces+gabriel.hurley=nebula.com [at] lists] On Behalf Of
>>> Mark Nottingham
>>> Sent: Tuesday, June 12, 2012 7:20 PM
>>> To: Jay Pipes
>>> Cc: openstack [at] lists<mailto:openstack [at] lists>
>>> 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 http://www.mnot.net/
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack [at] lists<mailto:openstack [at] lists>
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists<mailto:openstack [at] lists>
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>
> --
> Mark Nottingham http://www.mnot.net/
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists<mailto:openstack [at] lists>
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

--
Mark Nottingham http://www.mnot.net/




_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists<mailto:openstack [at] lists>
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists<mailto:openstack [at] lists>
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


jorge.williams at rackspace

Jun 15, 2012, 11:50 AM

Post #2 of 3 (204 views)
Permalink
Re: WADL [was: v3 API draft (update and questions to the community)] [In reply to]

All of the XSDs produced so far use XSD 1.1.

-jOrGe W.


On Jun 15, 2012, at 8:57 AM, Christopher B Ferris wrote:

+1

Over-reliance on WADL will only make it more challenging to gracefully evolve the APIs such that implementations can be forwards and/or backwards compatible, especially when exchanging XML based on an XSD that is not carefully crafted with proper extensibility points incorporated throughout the schema design, unless we were to adopt XSD1.1 which has an optional open content model (but which has not yet seen wide adoption, sadly).

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry and Cloud Standards
Member, IBM Academy of Technology
IBM Software Group, Standards Strategy
email: chrisfer [at] us<mailto:chrisfer [at] us>
Twitter: christo4ferris
phone: +1 508 234 2986


-----openstack-bounces+chrisfer=us.ibm.com [at] lists<mailto:-----openstack-bounces+chrisfer=us.ibm.com [at] lists> wrote: -----
To: "Nguyen, Liem Manh" <liem_m_nguyen [at] hp<mailto:liem_m_nguyen [at] hp>>
From: Mark Nottingham
Sent by: openstack-bounces+chrisfer=us.ibm.com [at] lists<mailto:openstack-bounces+chrisfer=us.ibm.com [at] lists>
Date: 06/14/2012 08:34PM
Cc: "openstack [at] lists<mailto:openstack [at] lists>" <openstack [at] lists<mailto:openstack [at] lists>>
Subject: [Openstack] WADL [was: v3 API draft (update and questions to the community)]

Hi Liem,

I'm one of the folks who helped Marc get WADL off of the ground. At the time, my use cases were exactly as you describe: documentation (e.g., <https://github.com/mnot/wadl_stylesheets>) and testing.

Even back then, there was a lot of discussion in the community; e.g., see:
http://bitworking.org/news/193/Do-we-need-WADL
http://old.nabble.com/Is-it-a-good-idea-to-make-your-WADL-available--tc6087155r1.html
http://www.25hoursaday.com/weblog/CommentView.aspx?guid=f88dc5a6-0aff-44ca-ba42-38c651612092

I think many of the concerns that were expressed then are still valid -- some even within these limited uses. In no particular order:

* People can and will use WADL to represent a "contract" to a service (really, an IDL), and "bake" client code to a snapshot of it in time. While it's true that the client and server need to have agreement about what goes on the wire and what it means, the assumptions around what guarantees WADL makes are not well-thought-out (in a manner similar to WSDL), making clients generated from it very tightly bound to the snapshot of the server they saw at some point in the past. This, in turn, makes evolution / extension of the API a lot harder than it needs to be.

* WADL's primitives are XML Schema datatypes. This is a horrible match for dynamic languages like Python.

* WADL itself embodies certain patterns of use that tend to show through if you design for it; these may or may not be the best patterns for a particular use case. This is because HTTP and URLs are very flexible things, and it isn't expressive enough to cover all of that space. As a result, you can end up with convoluted APIs that are designed to fit WADL, rather than do the task at hand.

>From what I've seen, many developers in OpenStack are profoundly uninterested in working with WADL. YMMV, but AFAICT this results in the WADL being done by other folks, and not matching the reality of the implementation; not a good situation for anyone.

What we need, I think, is a specification of the API that's precise, unambiguous, and easy to understand and maintain. I personally don't think WADL is up to that task (at least as a primary artefact), so (as I mentioned), I'm going to be proposing another approach.

Cheers,



On 15/06/2012, at 2:08 AM, Nguyen, Liem Manh wrote:

> 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.
>
> Liem
>
> -----Original Message-----
> From: openstack-bounces+liem_m_nguyen=hp.com [at] lists<mailto:openstack-bounces+liem_m_nguyen=hp.com [at] lists> [mailto:openstack-bounces+liem_m_nguyen=hp.com [at] lists] On Behalf Of Mark Nottingham
> Sent: Tuesday, June 12, 2012 8:43 PM
> To: Gabriel Hurley
> Cc: openstack [at] lists<mailto:openstack [at] lists>
> Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to the community)
>
>
> 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.
>
> Absolutely.
>
> 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 one).
>
> I should have something to show soon; if you're interested in helping out, that'd be great.
>
> Cheers,
>
>
>> My two cents,
>>
>> - Gabriel
>>
>>> -----Original Message-----
>>> From: openstack-bounces+gabriel.hurley=nebula.com [at] lists<mailto:openstack-bounces+gabriel.hurley=nebula.com [at] lists>
>>> [mailto:openstack-
>>> bounces+gabriel.hurley=nebula.com [at] lists] On Behalf Of
>>> Mark Nottingham
>>> Sent: Tuesday, June 12, 2012 7:20 PM
>>> To: Jay Pipes
>>> Cc: openstack [at] lists<mailto:openstack [at] lists>
>>> 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 http://www.mnot.net/
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack [at] lists<mailto:openstack [at] lists>
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists<mailto:openstack [at] lists>
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>
> --
> Mark Nottingham http://www.mnot.net/
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists<mailto:openstack [at] lists>
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

--
Mark Nottingham http://www.mnot.net/




_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists<mailto:openstack [at] lists>
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists<mailto:openstack [at] lists>
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


zhuadl at cn

Jun 17, 2012, 10:30 PM

Post #3 of 3 (193 views)
Permalink
Re: WADL [was: v3 API draft (update and questions to the community)] [In reply to]

+1
From the point view of software standards, Openstack API is evolving so
quickly and will be mostly likely standardized for IaaS. As a standard
interface, it need well described and carefully designed for developers.
The basis of a common understanding and agreement is important to adopt and
evolve in global. There're tremendous Standards are using Description
Languages to achieve this goal, especially for data model and APIs. I
believe it will make Openstack API more open, interoperable, easier of
integration with, smoothly to evolve.





Christopher B
Ferris
<chrisfer [at] us To
Sent by: cc
openstack-bounces "openstack [at] lists"
+zhuadl=cn.ibm.co <openstack [at] lists>
m [at] lists Subject
.net [Openstack] WADL [was: v3 API draft
(update and questions to the
community)]
2012-06-15
09:57








+1

Over-reliance on WADL will only make it more challenging to gracefully
evolve the APIs such that implementations can be forwards and/or backwards
compatible, especially when exchanging XML based on an XSD that is not
carefully crafted with proper extensibility points incorporated throughout
the schema design, unless we were to adopt XSD1.1 which has an optional
open content model (but which has not yet seen wide adoption, sadly).

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry and Cloud Standards
Member, IBM Academy of Technology
IBM Software Group, Standards Strategy
email: chrisfer [at] us
Twitter: christo4ferris
phone: +1 508 234 2986


-----openstack-bounces+chrisfer=us.ibm.com [at] lists wrote: -----
To: "Nguyen, Liem Manh" <liem_m_nguyen [at] hp>
From: Mark Nottingham
Sent by: openstack-bounces+chrisfer=us.ibm.com [at] lists
Date: 06/14/2012 08:34PM
Cc: "openstack [at] lists" <openstack [at] lists>
Subject: [Openstack] WADL [was: v3 API draft (update and questions to the
community)]

Hi Liem,

I'm one of the folks who helped Marc get WADL off of the ground. At the
time, my use cases were exactly as you describe: documentation (e.g., <
https://github.com/mnot/wadl_stylesheets>) and testing.

Even back then, there was a lot of discussion in the community; e.g., see:
http://bitworking.org/news/193/Do-we-need-WADL

http://old.nabble.com/Is-it-a-good-idea-to-make-your-WADL-available--tc6087155r1.html


http://www.25hoursaday.com/weblog/CommentView.aspx?guid=f88dc5a6-0aff-44ca-ba42-38c651612092


I think many of the concerns that were expressed then are still valid --
some even within these limited uses. In no particular order:

* People can and will use WADL to represent a "contract" to a service
(really, an IDL), and "bake" client code to a snapshot of it in time. While
it's true that the client and server need to have agreement about what goes
on the wire and what it means, the assumptions around what guarantees WADL
makes are not well-thought-out (in a manner similar to WSDL), making
clients generated from it very tightly bound to the snapshot of the server
they saw at some point in the past. This, in turn, makes evolution /
extension of the API a lot harder than it needs to be.

* WADL's primitives are XML Schema datatypes. This is a horrible match for
dynamic languages like Python.

* WADL itself embodies certain patterns of use that tend to show through if
you design for it; these may or may not be the best patterns for a
particular use case. This is because HTTP and URLs are very flexible
things, and it isn't expressive enough to cover all of that space. As a
result, you can end up with convoluted APIs that are designed to fit WADL,
rather than do the task at hand.

>From what I've seen, many developers in OpenStack are profoundly
uninterested in working with WADL. YMMV, but AFAICT this results in the
WADL being done by other folks, and not matching the reality of the
implementation; not a good situation for anyone.

What we need, I think, is a specification of the API that's precise,
unambiguous, and easy to understand and maintain. I personally don't think
WADL is up to that task (at least as a primary artefact), so (as I
mentioned), I'm going to be proposing another approach.

Cheers,



On 15/06/2012, at 2:08 AM, Nguyen, Liem Manh wrote:

> 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.
>
> Liem
>
> -----Original Message-----
> From: openstack-bounces+liem_m_nguyen=hp.com [at] lists [
mailto:openstack-bounces+liem_m_nguyen=hp.com [at] lists] On
Behalf Of Mark Nottingham
> Sent: Tuesday, June 12, 2012 8:43 PM
> To: Gabriel Hurley
> Cc: openstack [at] lists
> Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to
the community)
>
>
> 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.
>
> Absolutely.
>
> 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 one).
>
> I should have something to show soon; if you're interested in helping
out, that'd be great.
>
> Cheers,
>
>
>> My two cents,
>>
>> - Gabriel
>>
>>> -----Original Message-----
>>> From: openstack-bounces+gabriel.hurley=nebula.com [at] lists
>>> [mailto:openstack-
>>> bounces+gabriel.hurley=nebula.com [at] lists] On Behalf Of
>>> Mark Nottingham
>>> Sent: Tuesday, June 12, 2012 7:20 PM
>>> To: Jay Pipes
>>> Cc: openstack [at] lists
>>> 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 http://www.mnot.net/
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack [at] lists
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>
> --
> Mark Nottingham http://www.mnot.net/
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

--
Mark Nottingham http://www.mnot.net/




_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Attachments: graycol.gif (0.10 KB)
  pic12886.gif (1.23 KB)
  ecblank.gif (45 B)

OpenStack dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.