Open Stack

On 13/02/14 10:30 +0000, Jamie Hannaford wrote:
>I noticed a few things about the new 1.1 spec that I thought I'd give feedback
>on:
>
>1. Set Queue Metadata
>A PUT operation is provided, which does a hard replace of metadata values. New
>items are inserted, and existing items that are not specified are wiped. 
>
>Nova also provides a POST operation that is more sympathetic - allowing you to
>update only the values specified, leaving existing unspecified items
>unmodified. Could a similar operation be added to this API - since there
>definitely seems like a use case for it.

Neither PUT nor POST are the right methods to use here. I think we
discussed this at some point and we agreed on adding a PATCH action
for the queue metadata. This still needs to be discussed a bi further
though, even the queue metadata utility can be questionable as a
public feature.

I'd love to hear from you what kind of metadata would you put into the
queue and whether you think this is something useful for all users or
just operators.

The idea behind the queue metadata is to allow users to store
information relative to the queue and also customize some of the
queue's limits without exceeding the limits configured server side.

There are more use cases but I'd love to here some from you

>2. Get a Specific Message
>In the response body, the `href` field is provided as a relative URI - why?
>Surely absolute URIs are more convenient for the end-user.

This is because the client does the work of joining the relative path
to the host address. We had long discussions about whether we should
return the absolute URL as opposed to the relative URL. Although
relative are less convenient when "curling" the API, they are more
convenient when the client is doing this work for you and you have
several nodes you could talk to.

>
>3. Deleting Multiple Messages
>a. How does one delete multiple claimed messages? What would the URI template
>look like? It is not specified whether this is possible or not.
>b. If I provide a bunch of IDs, and one of them is a claimed message, what
>happens? Will it be silently ignored? The behavior is undefined.

Hehe, this is a good one! :)

So, as of now it is just possible to do bulk deletes which is a leaky
abstraction, TBH. This is a must fix issue for v1.1 because there's a
race condition that would allow A to delete a message that was
claimed by user B after getting it.


So, to answer:

a. you just do a bulk delete
b. it'd delete the message regardless it is claimed. :(

>
>4. Read a Shard
>Should these response structures be nested in a top-level "shard" object? Same
>will the "List Shards" collection.

Yes, there's a plan to make response more consistent, not sure if it
is mentioned there. :)

>
>5. The request body for Post Message(s) contains malformed JSON - the `=`
>should be `:`

Oh mmh, you mean in the spec, right?

>
>Sorry if some of these issues have already been settled or discussed :)
>


Thanks a lot for raising these questions and for reviewing the API
v1.1 spec.

Cheers,
Fla.

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140213/2dba2db1/attachment.pgp>