Open Stack

Hi, stackers

Since now we have merged filtering guideline[1], is that said we should
implement this feature according this guideline?  like this:

*"GET /app/items?f_updated_at=gte:some_timestamp"*

Do we have reached a consensus about this?

2015-06-19 17:07 GMT+08:00 Chris Dent <chdent at redhat.com>:

>
> There's an open question in the API-WG on whether to formalize or
> otherwise enshrine the concept of a "changes-since" query parameter
> on collection oriented resources across the projects. The original
> source of this concept is from Nova's API:
>
>
> http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html
>
> There are arguments for and against but we've been unable to reach a
> consensus so the agreed next step was to bring the issue to the
> mailing list so more people can hash it out and provide their input.
> The hope is that concerns or constraints that those in the group
> are not aware of will be revealed and a better decision will be
> reached.
>
> The basic idea of "changes-since" is that it can be used as a way to
> signal that the requestor is doing some polling and would like to
> ask "Give me stuff that has changed since the last time I checked".
> As I understand it, for the current implementations (in Nova and
> Glance) this means "including stuff that has been deleted". Repeated
> requests to the resource with a "changes-since" parameter gives a
> running report on the evolving state of the resource. This is intended
> to allow "efficient polling"[0].
>
> The pro camp on this likes it because this is very useful and quite
> humane: The requestor doesn't need to know the details of how the
> query is is implemented under the hood. That is, if there are
> several timestamps associated with the singular resources in the
> collection which of those are used for time comparison and which
> attributes (such as "state" with a value of "deleted") are used to
> determine if a singular resource is included. The service gets to
> decide these things and in order for "efficient polling" to actually
> be achieved it needs to do in order to make effective queries of the
> data store.
>
> The con camp doesn't like it because it introduces magic, ambiguity
> and inconsistency into the API (when viewed from a cross-project
> perspective) and one of the defining goals of the working group is
> to slowly guide things to some measure of consistency. The
> alternate approach is to formulate a fairly rigorous query system
> for both filtering[1] and sorting[2] and use that to specify
> explicit queries that state "I want resources that are newer than time
> X in timestamp attribute 'updated_at' _and_ have attribute 'state'
> that is one of 'foo', 'bar' or 'baz'".
>
> (I hope I have represented the two camps properly here and not
> introduced any bias. Myself I'm completely on the fence. If you
> think I've misrepresented the state of things please post a
> clarifying response.)
>
> The questions come down to:
>
> * Are there additional relevant pros and cons for the two proposals?
> * Are there additional proposals which can address the shortcomings
>   in either?
>
> Thanks for your input.
>
> [0] Please try to refrain from responses on the line of "ha!
>     efficiency! that's hilarious!" and "ZOMG, polling, that's so
>     last century". Everybody knows this already and it's not
>     germane to the immediate concerns. We'll get to a fully message
>     driven architecture next week. This week we're still working
>     with what we've got.
> [1] filtering guideline proposal
>     https://review.openstack.org/#/c/177468/
> [2] sorting guideline proposal
>     https://review.openstack.org/#/c/145579/
> --
> Chris Dent tw:@anticdent freenode:cdent
> https://tank.peermore.com/tanks/cdent
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best Wishes For You!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150810/b14b84d9/attachment.html>