openstack team mailing list archive

[Glen Campbell <glen.campbell@xxxxxxxxxxxxx>]

Having the <account> in the URL makes the resource cacheable (via HTTP, I
mean; you can always manually cache it, but that's not RESTful); without
it, you would need to require unique <container>s to uniquely reference a
cached copy.

On 2/14/11 7:57 PM, "Paul Voccio" <paul.voccio@xxxxxxxxxxxxx> wrote:

>Looking at the swift docs, they reference a container like so:
>
> METHOD /v1/<account>/<container> HTTP/1.1
>
>http://docs.rackspacecloud.com/files/api/v1/cf-devguide-20110112.pdf
>
>For the openstack api, it also includes the account id in the request:
>
>POST /v1.1/214412/images HTTP/1.1
>Host: servers.api.openstack.org
>Content-Type: application/json
>Accept: application/xml
>X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cb
>
>
>
>This seems a bit different than what you're suggesting. What am I missing?
>Shouldn't the account id be in the request with the auth headers to stay
>in line with the other specs?
>
>
>On 2/14/11 6:56 PM, "Eric Day" <eday@xxxxxxxxxxxx> wrote:
>
>>On Tue, Feb 15, 2011 at 12:49:01AM +0000, Paul Voccio wrote:
>>> Dropping the account_id, would this also assume that there can be more
>>> than one queue per account?
>>
>>Yeah. Think of the queue name as an extra namespace layer much like
>>a swift container, except you don't create or delete them, they just
>>exist when there is an active message in it.
>>
>>-Eric
>>
>>> On 2/14/11 5:54 PM, "Eric Day" <eday@xxxxxxxxxxxx> wrote:
>>> 
>>> >Yeah, for anonymous access that would be the case. Those are not
>>>needed
>>> >when the request comes in with OpenStack Auth headers (like nova).
>>> >
>>> >Do you think we should be repeating the account id in the URI when
>>> >the auth headers are present?
>>> >
>>> >-Eric
>>> >
>>> >On Mon, Feb 14, 2011 at 11:44:58PM +0000, Paul Voccio wrote:
>>> >> Eric,
>>> >> 
>>> >> Just looking at the http operations. Shouldn't the calls be around
>>>the
>>> >> account then the queue?
>>> >> 
>>> >> GET /$account_id/queue/id to list all the queues
>>> >> GET /$account_id/queue/id/message/id
>>> >> 
>>> >> Am I off here? Thoughts?
>>> >> 
>>> >> pvo
>>> >>   
>>> >> 
>>> >> On 2/14/11 5:07 PM, "Eric Day" <eday@xxxxxxxxxxxx> wrote:
>>> >> 
>>> >> >I've summarized the original email and added more sections for
>>>review
>>> >> >and discussion here:
>>> >> >
>>> >> >http://wiki.openstack.org/QueueService
>>> >> >
>>> >> >In particular there are details on the various components of the
>>> >> >queue service, a draft at what the REST operations will look like,
>>> >> >and a couple brief examples.
>>> >> >
>>> >> >Please let me know if any clarification is needed and I'll update
>>> >> >the wiki. Feedback and discussion on use cases and what you think
>>> >> >the service should look like is very appreciated.
>>> >> >
>>> >> >Thanks,
>>> >> >-Eric
>>> >> >
>>> >> >On Mon, Feb 14, 2011 at 09:51:42AM -0800, Eric Day wrote:
>>> >> >> Hi everyone,
>>> >> >> 
>>> >> >> When looking at other services to include as part of OpenStack,
>>>the
>>> >> >> first that comes to mind for many is a queue. A queue service can
>>> >> >> not only provide a useful public cloud service, but can also
>>>provide
>>> >> >> one of the building blocks for other services. I've been leading
>>>an
>>> >> >> effort to research and gather requirements for a queue service
>>>and
>>> >> >> I'd like to share the current state and get community feedback. I
>>> >> >> expect real development to begin very soon, and would also like
>>>to
>>> >> >> identify developers who will have time to dedicate to this
>>>project.
>>> >> >> 
>>> >> >> I'd like to note this is not an official OpenStack project yet.
>>>The
>>> >> >> intention is once we have the community support and a simple
>>> >> >> implementation, we will submit the project to the OpenStack
>>>Project
>>> >> >> Oversight Committee for approval.
>>> >> >> 
>>> >> >> The reason we are initiating our own project vs using an existing
>>>one
>>> >> >> is due to simplicity, modularity, and scale. Also, very few (if
>>>any)
>>> >> >> existing queue systems out there were built with multi-tenant
>>>cloud
>>> >> >> use cases in mind. Very few also have a simple and extensible
>>>REST
>>> >> >> API. There are possible solutions to build an AMQP based service,
>>> >> >> but AMQP brings complexity and a protocol not optimized for high
>>> >> >> latency and intermittent connectivity.
>>> >> >> 
>>> >> >> The primary goals of the queue service are:
>>> >> >> 
>>> >> >> * Simple - Think simple REST based queues for most use cases.
>>>Easy
>>> >> >>   to access and use from any language. It should not require much
>>> >> >>   setup, if any, before you can start pushing messages into it.
>>> >> >> 
>>> >> >> * Modular API - Initially we'll focus on a simple REST API,
>>> >> >>   but this will not in any way be a first-class API. It should be
>>> >> >>   possible to add other protocols (AMQP, protocol buffers,
>>>Gearman,
>>> >> >>   etc) for other use cases. Note that the internal service API
>>>will
>>> >> >>   not always provide a 1-1 mapping with the external API, so some
>>> >> >>   features with advanced protocols may be unavailable.
>>> >> >> 
>>> >> >> * Fast - Since this will act as a building block for other
>>>services
>>> >> >>   that my drive heavy throughput, performance will have a focus.
>>>This
>>> >> >>   mostly comes down to implementation language and how clients
>>>and
>>> >> >>   workers interact with the broker to reduce network chatter.
>>> >> >> 
>>> >> >> * Multi-tenant - Support multiple accounts for the service, and
>>>since
>>> >> >>   this will also be a public service for some deployments,
>>>protect
>>> >> >>   against potentially malicious users.
>>> >> >> 
>>> >> >> * Persistent - Allow messages to optionally be persistent. For
>>> >> >>   protocols that can support it, this can be an optional flag
>>>while
>>> >> >>   the message is submitted. The persistent storage should also be
>>> >> >>   modular so we can test various data stores and accommodate
>>> >>different
>>> >> >>   deployment options.
>>> >> >> 
>>> >> >> * Zones and locality awareness - As we've been discussing in
>>>other
>>> >> >>   threads, locality in cloud services is an important feature.
>>>When
>>> >> >>   dealing with where messages should be processed, we need to
>>>have
>>> >> >>   location awareness to process data where it exists to reduce
>>> >>network
>>> >> >>   overhead and processing time.
>>> >> >> 
>>> >> >> Before diving down into implementation details, I would like to
>>>hear
>>> >> >> what folks have to say about the initial requirements above. Once
>>> >> >> there is something along the lines of agreement, I'll be sending
>>>out
>>> >> >> other topics for discussion dealing with implementation.
>>> >> >> 
>>> >> >> I'm looking forward to your feedback. Thanks!
>>> >> >> 
>>> >> >> -Eric
>>> >> >
>>> >> >_______________________________________________
>>> >> >Mailing list: https://launchpad.net/~openstack
>>> >> >Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> >> >Unsubscribe : https://launchpad.net/~openstack
>>> >> >More help   : https://help.launchpad.net/ListHelp
>>> >> 
>>> >> 
>>> >> 
>>> >> Confidentiality Notice: This e-mail message (including any attached
>>>or
>>> >> embedded documents) is intended for the exclusive and confidential
>>>use
>>> >>of the
>>> >> individual or entity to which this message is addressed, and unless
>>> >>otherwise
>>> >> expressly indicated, is confidential and privileged information of
>>> >>Rackspace.
>>> >> Any dissemination, distribution or copying of the enclosed material
>>>is
>>> >>prohibited.
>>> >> If you receive this transmission in error, please notify us
>>>immediately
>>> >>by e-mail
>>> >> at abuse@xxxxxxxxxxxxx, and delete the original message.
>>> >> Your cooperation is appreciated.
>>> 
>>> 
>>> 
>>> Confidentiality Notice: This e-mail message (including any attached or
>>> embedded documents) is intended for the exclusive and confidential use
>>>of the
>>> individual or entity to which this message is addressed, and unless
>>>otherwise
>>> expressly indicated, is confidential and privileged information of
>>>Rackspace. 
>>> Any dissemination, distribution or copying of the enclosed material is
>>>prohibited.
>>> If you receive this transmission in error, please notify us immediately
>>>by e-mail
>>> at abuse@xxxxxxxxxxxxx, and delete the original message.
>>> Your cooperation is appreciated.
>
>
>
>Confidentiality Notice: This e-mail message (including any attached or
>embedded documents) is intended for the exclusive and confidential use of
>the
>individual or entity to which this message is addressed, and unless
>otherwise
>expressly indicated, is confidential and privileged information of
>Rackspace.
>Any dissemination, distribution or copying of the enclosed material is
>prohibited.
>If you receive this transmission in error, please notify us immediately
>by e-mail
>at abuse@xxxxxxxxxxxxx, and delete the original message.
>Your cooperation is appreciated.
>
>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp