Re: [Openstack] Entities in OpenStack Auth
Hi Eric, interesting proposal. Comments inline. On Tue, Mar 1, 2011 at 9:14 PM, Eric Day e...@oddments.org wrote: For that query you would, but not all. If you want to create a new instance for project1 you would: nova.openstack.org/v1.1/project1/servers Or if you wanted to reboot instance X in project1: nova.openstack.org/v1.1/project1/servers/X Note that the following resource is not the same as the last, since justin wouldn't be the owner for instance X, project1 would be: nova.openstack.org/v1.1/justin/servers/X I think searches will always have special cases with filter options, but for identifying a canonical URL for a resource, having the entity name of the owner in there seems correct. The main thing I'm trying to figure out is whether to use an extra entity in the path for new service URLs. Swift does and Nova does not, and it would be nice to have some consistency. I see the benefits of both, and in Swift's case it needs to for simple public URLs (where there is no user context). Are you proposing that an entity always be the owner of something? If so, I dislike using the term entity, since entity does not imply ownership. I'd prefer owner or account, since the latter implies control over something. Entity connotes neither ownership nor control. I'd like to get the semantics around these terms correct. We've already run into numerous issues with the term metadata and I really don't feel like introducing another source of confusion in both the documentation and the code comments. -jay -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Entities in OpenStack Auth
On Tue, Mar 1, 2011 at 7:46 PM, Monsyne Dragon mdra...@rackspace.com wrote: On 3/1/11 6:32 PM, Justin Santa Barbara wrote: 2) Preclude us from having e.g. multi-project queries (show me all my servers in projects A and B)? It doesn't really preclude multi-account queries, if they are needed. You would be 'logged in' under a given account, but queries could potentially return info based on wider criteria, given user permissions. Also, since the server management url is dynamic (see above) it's easy to change that in the future if needed. Could you give an example URL you're thinking of, because I can't visualise how the above would look like. Thanks! -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Entities in OpenStack Auth
Swift Swift has the concept of accounts, users, and groups. An account contains users, and a user can belong to groups. Accounts names have an abstraction layer, so while you may login with account example.com, the account name used within swift is a UUID with a prefix. By default, a user belongs to a group for the user user:account and a group for the account account. The other group names can be arbitrary strings, so they may be other account names, users, or some application-specific term. All operations are done in the context of a user and account. A user may not be a member of the account it's acting on since resources can specify ACLs, this is especially true for public resources (where user is undefined or anonymous). To be clear, users in swift are entirely a function of the auth middleware. Once you get past middleware, swift only has a concept of accounts, which are designated in the URL. The middleware decides whether or not you have access to that account based on info in the request (or combined with metadata stored in swift, which is how ACLs are implemented). The Cloud Files installation, for example, has no concept of multiple users in an account, because its authentication system doesn't. -- Mike ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Entities in OpenStack Auth
On Wed, Mar 02, 2011 at 05:07:04AM -0600, Michael Barton wrote: Swift Swift has the concept of accounts, users, and groups. An account contains users, and a user can belong to groups. Accounts names have an abstraction layer, so while you may login with account example.com, the account name used within swift is a UUID with a prefix. By default, a user belongs to a group for the user user:account and a group for the account account. The other group names can be arbitrary strings, so they may be other account names, users, or some application-specific term. All operations are done in the context of a user and account. A user may not be a member of the account it's acting on since resources can specify ACLs, this is especially true for public resources (where user is undefined or anonymous). To be clear, users in swift are entirely a function of the auth middleware. Once you get past middleware, swift only has a concept of accounts, which are designated in the URL. The middleware decides whether or not you have access to that account based on info in the request (or combined with metadata stored in swift, which is how ACLs are implemented). The Cloud Files installation, for example, has no concept of multiple users in an account, because its authentication system doesn't. Thanks for the clarification. Perhaps I should restate my proposal in terms of 'accounts' instead of 'entities', as this already maps closely to what Swift does. -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
Re: [Openstack] Entities in OpenStack Auth
I like this idea, but I have some concerns about the feasibility of successfully differentiating between users and projects. While it's easy to query one data store and then the next, perhaps we can avoid this issue by assigning unique identifiers to resources? Show all servers in project1: GET http://nova.openstack.org/v1.1/servers?project=project1 Show Instance X: GET http://nova.openstack.org/v1.1/servers/-F5*ovBi-=rYdW3leIGY Show all servers available to current user: GET http://nova.openstack.org/v1.1/servers Unique identifiers for items, while many feel they are cumbersome, provide a couple benefits I can think of off the top of my head: 1) Easy permalinks (ability to re-name everything else about the server without worrying about the URL changing) 2) Public URLs no longer need any other identifying information because they are now unique. Problems include things like me not knowing the intricacies of the OpenStack database which might make my first example more difficult. Also, some people like URLs to be readable and/or memorable. -Original Message- From: Eric Day e...@oddments.org Sent: Tuesday, March 1, 2011 9:14pm To: Justin Santa Barbara jus...@fathomdb.com Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Entities in OpenStack Auth For that query you would, but not all. If you want to create a new instance for project1 you would: nova.openstack.org/v1.1/project1/servers Or if you wanted to reboot instance X in project1: nova.openstack.org/v1.1/project1/servers/X Note that the following resource is not the same as the last, since justin wouldn't be the owner for instance X, project1 would be: nova.openstack.org/v1.1/justin/servers/X I think searches will always have special cases with filter options, but for identifying a canonical URL for a resource, having the entity name of the owner in there seems correct. The main thing I'm trying to figure out is whether to use an extra entity in the path for new service URLs. Swift does and Nova does not, and it would be nice to have some consistency. I see the benefits of both, and in Swift's case it needs to for simple public URLs (where there is no user context). -Eric On Tue, Mar 01, 2011 at 06:00:12PM -0800, Justin Santa Barbara wrote: If we're always going to pass the same user-id token (for a particular user), what's the value in passing it at all? Why not get it from the authentication token? e.g. my X-Auth-Token could look like: justinsb project1,project2,project3 5OPr9UR2xk32K9ArAjO562e (i.e. my username, projects and a crypto signature) Justin On Tue, Mar 1, 2011 at 5:51 PM, Eric Day e...@oddments.org wrote: Hi Justin, On Tue, Mar 01, 2011 at 05:14:42PM -0800, Justin Santa Barbara wrote: However, what I don't understand is how I can query my servers in project1 and project2 (but not those in project3). *The only way I could see is doing something like this: *nova.openstack.org/v1.1/project1+project2/servers. I agree that REST paths aren't themselves hacky in the single-project case, but I don't yet grok the multi-project query. *Of the 3 options I do grok, I see (c) as the least hacky. I would probably say use nova.openstack.org/v1.1/justin/servers with one or more filter parameters in the URL or body as you mention. This something to consider across all services, not just nova. AFAIK Swift doesn't support queries across multiple accounts right now, so I'd like to hear their thoughts on it as well. -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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Entities in OpenStack Auth
Hi Brian, The proposal abstracts 'users' and 'projects' to just 'entities', although we may want to use 'accounts' since this already maps to how swift works. So a user is an account, a project is an account, and accounts can give access to other accounts (possibly with specific roles). Therefore the query to list all servers in project1 is really deployment specific, and could just be: GET http://nova.openstack.org/v1.1/project1/servers Which is just an application of the generic: GET http://nova.openstack.org/v1.1/account/servers As I mentioned before, we'll probably want search options for depth so it can include nested accounts and filters. For example: GET http://nova.openstack.org/v1.1/user1/servers?depth=2filter=proj1,proj2 Here user1, proj1, and proj2 are all account names. As for unique IDs, this again is something we should probably try to be consistent on across services. With nova today, ID's are only unique within a cluster (shared DB instance), so two clusters would currently clash. We need something more than just a unique ID when we start connecting public and private clouds. You can't control the unique ID generation so a bad private cloud could start duplicating 'unique' ID's on purpose. We need some namespace to prevent these collisions and limit the damage, and account seems like the most appropriate (and matches what Swift does, so there is some consistency). -Eric On Wed, Mar 02, 2011 at 01:45:43PM -0500, Brian Lamar wrote: I like this idea, but I have some concerns about the feasibility of successfully differentiating between users and projects. While it's easy to query one data store and then the next, perhaps we can avoid this issue by assigning unique identifiers to resources? Show all servers in project1: GET http://nova.openstack.org/v1.1/servers?project=project1 Show Instance X: GET http://nova.openstack.org/v1.1/servers/-F5*ovBi-=rYdW3leIGY Show all servers available to current user: GET http://nova.openstack.org/v1.1/servers Unique identifiers for items, while many feel they are cumbersome, provide a couple benefits I can think of off the top of my head: 1) Easy permalinks (ability to re-name everything else about the server without worrying about the URL changing) 2) Public URLs no longer need any other identifying information because they are now unique. Problems include things like me not knowing the intricacies of the OpenStack database which might make my first example more difficult. Also, some people like URLs to be readable and/or memorable. -Original Message- From: Eric Day e...@oddments.org Sent: Tuesday, March 1, 2011 9:14pm To: Justin Santa Barbara jus...@fathomdb.com Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Entities in OpenStack Auth For that query you would, but not all. If you want to create a new instance for project1 you would: nova.openstack.org/v1.1/project1/servers Or if you wanted to reboot instance X in project1: nova.openstack.org/v1.1/project1/servers/X Note that the following resource is not the same as the last, since justin wouldn't be the owner for instance X, project1 would be: nova.openstack.org/v1.1/justin/servers/X I think searches will always have special cases with filter options, but for identifying a canonical URL for a resource, having the entity name of the owner in there seems correct. The main thing I'm trying to figure out is whether to use an extra entity in the path for new service URLs. Swift does and Nova does not, and it would be nice to have some consistency. I see the benefits of both, and in Swift's case it needs to for simple public URLs (where there is no user context). -Eric On Tue, Mar 01, 2011 at 06:00:12PM -0800, Justin Santa Barbara wrote: If we're always going to pass the same user-id token (for a particular user), what's the value in passing it at all? Why not get it from the authentication token? e.g. my X-Auth-Token could look like: justinsb project1,project2,project3 5OPr9UR2xk32K9ArAjO562e (i.e. my username, projects and a crypto signature) Justin On Tue, Mar 1, 2011 at 5:51 PM, Eric Day e...@oddments.org wrote: Hi Justin, On Tue, Mar 01, 2011 at 05:14:42PM -0800, Justin Santa Barbara wrote: However, what I don't understand is how I can query my servers in project1 and project2 (but not those in project3). *The only way I could see is doing something like this: *nova.openstack.org/v1.1/project1+project2/servers. I agree that REST paths aren't themselves hacky in the single-project case, but I don't yet grok the multi-project query. *Of the 3 options I do grok, I see (c) as the least hacky. I would probably say use nova.openstack.org/v1.1/justin/servers with one or more filter parameters in the URL or body
Re: [Openstack] Entities in OpenStack Auth
According to the proposed API 1.1 spec, it *does* use an extra element in the path to indicate the account; this is (presumably) returned by the auth system: http://servers.api.openstack.org/v1.1/1234/servers/12 Where 1234 is the account ID (actually a token, I believe) and 12 is the server ID. See p. 5 of the latest API 1.1 doc. On 3/1/11 8:14 PM, Eric Day e...@oddments.org wrote: For that query you would, but not all. If you want to create a new instance for project1 you would: nova.openstack.org/v1.1/project1/servers Or if you wanted to reboot instance X in project1: nova.openstack.org/v1.1/project1/servers/X Note that the following resource is not the same as the last, since justin wouldn't be the owner for instance X, project1 would be: nova.openstack.org/v1.1/justin/servers/X I think searches will always have special cases with filter options, but for identifying a canonical URL for a resource, having the entity name of the owner in there seems correct. The main thing I'm trying to figure out is whether to use an extra entity in the path for new service URLs. Swift does and Nova does not, and it would be nice to have some consistency. I see the benefits of both, and in Swift's case it needs to for simple public URLs (where there is no user context). -Eric On Tue, Mar 01, 2011 at 06:00:12PM -0800, Justin Santa Barbara wrote: If we're always going to pass the same user-id token (for a particular user), what's the value in passing it at all? Why not get it from the authentication token? e.g. my X-Auth-Token could look like: justinsb project1,project2,project3 5OPr9UR2xk32K9ArAjO562e (i.e. my username, projects and a crypto signature) Justin On Tue, Mar 1, 2011 at 5:51 PM, Eric Day e...@oddments.org wrote: Hi Justin, On Tue, Mar 01, 2011 at 05:14:42PM -0800, Justin Santa Barbara wrote: However, what I don't understand is how I can query my servers in project1 and project2 (but not those in project3). *The only way I could see is doing something like this: *nova.openstack.org/v1.1/project1+project2/servers. I agree that REST paths aren't themselves hacky in the single-project case, but I don't yet grok the multi-project query. *Of the 3 options I do grok, I see (c) as the least hacky. I would probably say use nova.openstack.org/v1.1/justin/servers with one or more filter parameters in the URL or body as you mention. This something to consider across all services, not just nova. AFAIK Swift doesn't support queries across multiple accounts right now, so I'd like to hear their thoughts on it as well. -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. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Entities in OpenStack Auth
On Wed, Mar 02, 2011 at 07:43:08PM +, Glen Campbell wrote: According to the proposed API 1.1 spec, it *does* use an extra element in the path to indicate the account; this is (presumably) returned by the auth system: http://servers.api.openstack.org/v1.1/1234/servers/12 Where 1234 is the account ID (actually a token, I believe) and 12 is the server ID. See p. 5 of the latest API 1.1 doc. Thanks, I saw Jorge pointed that out earlier as well. With that, this discussion is more focused on how this maps to 'users' and 'projects' in nova and how to list servers (or any resource) across multiple accounts. On 3/1/11 8:14 PM, Eric Day e...@oddments.org wrote: For that query you would, but not all. If you want to create a new instance for project1 you would: nova.openstack.org/v1.1/project1/servers Or if you wanted to reboot instance X in project1: nova.openstack.org/v1.1/project1/servers/X Note that the following resource is not the same as the last, since justin wouldn't be the owner for instance X, project1 would be: nova.openstack.org/v1.1/justin/servers/X I think searches will always have special cases with filter options, but for identifying a canonical URL for a resource, having the entity name of the owner in there seems correct. The main thing I'm trying to figure out is whether to use an extra entity in the path for new service URLs. Swift does and Nova does not, and it would be nice to have some consistency. I see the benefits of both, and in Swift's case it needs to for simple public URLs (where there is no user context). -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
Re: [Openstack] Entities in OpenStack Auth
On 3/1/11 6:11 PM, Eric Day wrote: [ ... trimmed ... ] For the OpenStack API, we need something a bit different from what we have today. We currently have no way of passing in a project name, so I propose we add an entity element to the path name (just like Swift does). For example, instead of /v1.0/servers/1, it would be /v1.0/entity/servers/1, where entity can represent an account (like swift), project (like current nova), or even a user entity (deployments where projects or accounts are not used). Our window for OpenStack API changes is still open as it's still under heavy development, and I think this path addition will provide more functionality and a consistent structure across services (glance and burrow will be using an account or entity in the path as well). FYI: the multitenant blueprint, which I will be proposing for merge later today or early tomorrow, does just this to pass the project name in. -- -- -Monsyne Dragon work: 210-312-4190 mobile210-441-0965 google voice: 210-338-0336 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
Re: [Openstack] Entities in OpenStack Auth
Won't putting this in the URL both: 1) Break CloudServers API compatibility (a total no-no)? and 2) Preclude us from having e.g. multi-project queries (show me all my servers in projects A and B)? The options I see open to us are: a) A cookie / header b) A query parameter c) Something in the request body I like (c) because it's the least hacky and is not tied to HTTP. Justin On Tue, Mar 1, 2011 at 4:23 PM, Monsyne Dragon mdra...@rackspace.comwrote: On 3/1/11 6:11 PM, Eric Day wrote: [ ... trimmed ... ] For the OpenStack API, we need something a bit different from what we have today. We currently have no way of passing in a project name, so I propose we add an entity element to the path name (just like Swift does). For example, instead of /v1.0/servers/1, it would be /v1.0/entity/servers/1, where entity can represent an account (like swift), project (like current nova), or even a user entity (deployments where projects or accounts are not used). Our window for OpenStack API changes is still open as it's still under heavy development, and I think this path addition will provide more functionality and a consistent structure across services (glance and burrow will be using an account or entity in the path as well). FYI: the multitenant blueprint, which I will be proposing for merge later today or early tomorrow, does just this to pass the project name in. -- -- -Monsyne Dragon work: 210-312-4190 mobile210-441-0965 google voice: 210-338-0336 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Entities in OpenStack Auth
Hi Justin, On Tue, Mar 01, 2011 at 05:14:42PM -0800, Justin Santa Barbara wrote: However, what I don't understand is how I can query my servers in project1 and project2 (but not those in project3). *The only way I could see is doing something like this: *nova.openstack.org/v1.1/project1+project2/servers. I agree that REST paths aren't themselves hacky in the single-project case, but I don't yet grok the multi-project query. *Of the 3 options I do grok, I see (c) as the least hacky. I would probably say use nova.openstack.org/v1.1/justin/servers with one or more filter parameters in the URL or body as you mention. This something to consider across all services, not just nova. AFAIK Swift doesn't support queries across multiple accounts right now, so I'd like to hear their thoughts on it as well. -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
Re: [Openstack] Entities in OpenStack Auth
If we're always going to pass the same user-id token (for a particular user), what's the value in passing it at all? Why not get it from the authentication token? e.g. my X-Auth-Token could look like: justinsb project1,project2,project3 5OPr9UR2xk32K9ArAjO562e (i.e. my username, projects and a crypto signature) Justin On Tue, Mar 1, 2011 at 5:51 PM, Eric Day e...@oddments.org wrote: Hi Justin, On Tue, Mar 01, 2011 at 05:14:42PM -0800, Justin Santa Barbara wrote: However, what I don't understand is how I can query my servers in project1 and project2 (but not those in project3). *The only way I could see is doing something like this: *nova.openstack.org/v1.1/project1+project2/servers. I agree that REST paths aren't themselves hacky in the single-project case, but I don't yet grok the multi-project query. *Of the 3 options I do grok, I see (c) as the least hacky. I would probably say use nova.openstack.org/v1.1/justin/servers with one or more filter parameters in the URL or body as you mention. This something to consider across all services, not just nova. AFAIK Swift doesn't support queries across multiple accounts right now, so I'd like to hear their thoughts on it as well. -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
Re: [Openstack] Entities in OpenStack Auth
Eric, I think that¹s an interesting proposal. I think I'll try to put something together to visual this. pvo On 3/1/11 8:14 PM, Eric Day e...@oddments.org wrote: For that query you would, but not all. If you want to create a new instance for project1 you would: nova.openstack.org/v1.1/project1/servers Or if you wanted to reboot instance X in project1: nova.openstack.org/v1.1/project1/servers/X Note that the following resource is not the same as the last, since justin wouldn't be the owner for instance X, project1 would be: nova.openstack.org/v1.1/justin/servers/X I think searches will always have special cases with filter options, but for identifying a canonical URL for a resource, having the entity name of the owner in there seems correct. The main thing I'm trying to figure out is whether to use an extra entity in the path for new service URLs. Swift does and Nova does not, and it would be nice to have some consistency. I see the benefits of both, and in Swift's case it needs to for simple public URLs (where there is no user context). -Eric On Tue, Mar 01, 2011 at 06:00:12PM -0800, Justin Santa Barbara wrote: If we're always going to pass the same user-id token (for a particular user), what's the value in passing it at all? Why not get it from the authentication token? e.g. my X-Auth-Token could look like: justinsb project1,project2,project3 5OPr9UR2xk32K9ArAjO562e (i.e. my username, projects and a crypto signature) Justin On Tue, Mar 1, 2011 at 5:51 PM, Eric Day e...@oddments.org wrote: Hi Justin, On Tue, Mar 01, 2011 at 05:14:42PM -0800, Justin Santa Barbara wrote: However, what I don't understand is how I can query my servers in project1 and project2 (but not those in project3). *The only way I could see is doing something like this: *nova.openstack.org/v1.1/project1+project2/servers. I agree that REST paths aren't themselves hacky in the single-project case, but I don't yet grok the multi-project query. *Of the 3 options I do grok, I see (c) as the least hacky. I would probably say use nova.openstack.org/v1.1/justin/servers with one or more filter parameters in the URL or body as you mention. This something to consider across all services, not just nova. AFAIK Swift doesn't support queries across multiple accounts right now, so I'd like to hear their thoughts on it as well. -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. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
