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" <e...@oddments.org> 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" <e...@oddments.org> 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@lists.launchpad.net > >> >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 ab...@rackspace.com, 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 ab...@rackspace.com, and delete the original message. > Your cooperation is appreciated. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
