Re: [Openstack] Entities in OpenStack Auth

2011-03-02 Thread Michael Barton
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

Re: [Openstack] server affinity

2011-03-02 Thread Jorge Williams
Metadata in the OpenStack Compute/Cloud Servers API is meant to describe user defined properties. That's it. So in that case, I agree with Brian that we shouldn't be overloading that functionality by performing some action based on user-defined metadata. Speaking more generally though, any

Re: [Openstack] server affinity

2011-03-02 Thread Sandy Walsh
I think these additional/optional request parameters (aka metadata) should just be part of the context that is created when a command is issued and passed around for all services to use as needed. So I guess that would be a vote for #2 -S From: Jorge

Re: [Openstack] State of OpenStack Auth

2011-03-02 Thread Jorge Williams
Soren, Really good question about why we didn't use cookies. There are two problems that I see with cookies. 1) Weak support in HTTP client libraries. HTTP libs tend to not handle them at all or to not handle them correctly. In the Java world, for example, java.net.* doesn't handle cookies

Re: [Openstack] server affinity

2011-03-02 Thread Mark Washenberger
[W]e shouldn't be overloading that functionality by performing some action based on user-defined metadata. That is exactly what I've been trying to say, but you have stated it much more succinctly. Thanks! My specific concern is with quotas. If the current osapi metadata is overloaded with

Re: [Openstack] State of OpenStack Auth

2011-03-02 Thread Soren Hansen
2011/3/2 Jorge Williams jorge.willi...@rackspace.com: 1)  Weak support in HTTP client libraries. a) This surprises me. I definitely remember using cookies with several different http libraries. b) There is *no* support for the current alternative, since it's something that was made up for this

Re: [Openstack] State of OpenStack Auth

2011-03-02 Thread Jorge Williams
We can certainly try your suggestions but I think the path of least resistance is to support an existing authentication scheme. You're right in stating that the semantics are extremely close to cookies. I'd note that http auth schemes almost always work in the exact same way -- that is client

[Openstack] OpenStack Compute 1.1

2011-03-02 Thread Jorge Williams
Hey guys, New version of OpenStack Compute 1.1 is out. PDF: http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf WebHelp: http://docs.openstack.org/openstack-compute/developer/content/ See the Document Change History section for a list of changes. The API is now in Launchpad

Re: [Openstack] State of OpenStack Auth

2011-03-02 Thread Michael Barton
a secure channel too, but if not attacks are less severe since they are limited to reply attacks only (the request and parameters are used as part of the signature). We can easily support both (and others), but we need to understand the needs and constraints of each. HMAC is sort of appealing

Re: [Openstack] OpenStack Compute 1.1

2011-03-02 Thread Justin Santa Barbara
Looks like some good changes. Where is this in launchpad, so the community can help develop it? For example, I'm willing to document the reservation of the aws: prefix. Justin On Wed, Mar 2, 2011 at 8:29 AM, Jorge Williams jorge.willi...@rackspace.com wrote: Hey guys, New version of

Re: [Openstack] OpenStack Compute 1.1

2011-03-02 Thread Michael Mayo
Should comments/suggestions go in this email thread or in the comments sections of the web help? I hate to spam this list :) Mike On Mar 2, 2011, at 8:29 AM, Jorge Williams wrote: Hey guys, New version of OpenStack Compute 1.1 is out. PDF:

Re: [Openstack] server affinity

2011-03-02 Thread Eric Day
Well said Jorge. I think we're all in agreement that we need a way to add both user-defined metadata and service-specific metadata (and possibly deployment-specific metadata). I think Justin was working on the metadata mechanisms assuming it would support both based on prefix. If we don't want to

Re: [Openstack] Entities in OpenStack Auth

2011-03-02 Thread Eric Day
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

Re: [Openstack] server affinity

2011-03-02 Thread Justin Santa Barbara
Thanks Eric: +1, and I appreciate the peace-brokering :-) I'm not wedded to the idea of putting service metadata into the same collection as user metadata; it just seems like a reasonable approach to me. But it's more important to me that we agree on something, than that we agree on the best

Re: [Openstack] Entities in OpenStack Auth

2011-03-02 Thread Brian Lamar
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:

Re: [Openstack] OpenStack Compute 1.1

2011-03-02 Thread Eric Day
Thanks Jorge, this looks good. The 'affinityId' name is better than 'location' as I've been using to describe it. I propose affinity ID be a common (optional) property among all openstack services when it makes sense, so I would suggest we add it to network, volume, and if the swift guys are up

Re: [Openstack] Entities in OpenStack Auth

2011-03-02 Thread Eric Day
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

Re: [Openstack] server affinity

2011-03-02 Thread Eric Day
On Wed, Mar 02, 2011 at 01:31:27PM -0500, Brian Lamar wrote: Wait, are we all in agreement that we need user-defined metadata and service-specific metadata? I do agree that the data store isn't conducive to adding arbitrary metadata due to the rigidness of our DB, but how often are we going

Re: [Openstack] server affinity

2011-03-02 Thread Eric Day
On Wed, Mar 02, 2011 at 10:27:33AM -0800, Justin Santa Barbara wrote: I'm not wedded to the idea of putting service metadata into the same collection as user metadata; it just seems like a reasonable approach to me. *But it's more important to me that we agree on something, than that

Re: [Openstack] server affinity

2011-03-02 Thread Todd Willey
I like prefixed names that are grouped in with user metadata. On Wed, Mar 2, 2011 at 1:30 PM, Eric Day e...@oddments.org wrote: On Wed, Mar 02, 2011 at 01:31:27PM -0500, Brian Lamar wrote: Wait, are we all in agreement that we need user-defined metadata and service-specific metadata? I do

Re: [Openstack] Entities in OpenStack Auth

2011-03-02 Thread Glen Campbell
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.

Re: [Openstack] Entities in OpenStack Auth

2011-03-02 Thread Eric Day
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

Re: [Openstack] OpenStack Compute API for Cactus (critical!)

2011-03-02 Thread Eric Day
I havn't seen much activity on this, so though I'd do a quick brain dump of what I'm aware of: Auth/global: * Ability to lockout a user for some time period after failed auth. * Describe zones and regions (replaced with Sandy's zone work). Admin * Describe instance types (list flavors). * CRUD

Re: [Openstack] OpenStack Compute 1.1

2011-03-02 Thread Rick Clark
Jorge, I thought this was supposed released as Creative Commons. All I can find is the text below, which is not open. I think this is not appropriate for something released as a part of openstack. Rick API v1.1 (03/01/11) Copyright © 2009-2011 Rackspace US, Inc. All rights reserved. This

Re: [Openstack] State of OpenStack Auth

2011-03-02 Thread Soren Hansen
2011/3/2 Michael Barton mike-launch...@weirdlooking.com: HMAC is sort of appealing for Swift, since it'd let people choose to use HTTP instead of HTTPS for data that's not sensitive. I'd like to just mention this blog post: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

Re: [Openstack] State of OpenStack Auth

2011-03-02 Thread Michael Barton
On Wed, Mar 2, 2011 at 2:38 PM, Soren Hansen so...@ubuntu.com wrote: I'd like to just mention this blog post:   http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html tl;dr quote:    If you stop reading now you only need to remember one thing:    SSL/TLS is not computationally

[Openstack] OS API server password generation

2011-03-02 Thread Dan Prince
We created a blueprint on adding support for password generation when creating servers. This is needed for Openstack API/Cloud Servers API v1.0 parity. We are anxious to get this work started so if you are interested please review the following:  

Re: [Openstack] State of OpenStack Auth

2011-03-02 Thread Soren Hansen
2011/3/2 Michael Barton mike-launch...@weirdlooking.com: On Wed, Mar 2, 2011 at 2:38 PM, Soren Hansen so...@ubuntu.com wrote: I'd like to just mention this blog post:   http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html tl;dr quote:    If you stop reading now you only need to

Re: [Openstack] OpenStack Compute 1.1

2011-03-02 Thread Anne Gentle
Ok, you win the sharp eyes award. :) The front cover also has the Rackspace logo rather than the OpenStack logo. The PDF just needs to be re-built using the Apache license indicator. Jorge built that output capability for OpenStack specifically, but he just didn't re-run the PDF build yet - we

Re: [Openstack] server affinity

2011-03-02 Thread Jorge Williams
On Mar 2, 2011, at 11:43 AM, Eric Day wrote: Now the arguments stated by many folks is that service_metadata is really instance properties or instance attributes and should instead be part of the instance object/record directly (like size, flavor id, etc. are). I don't disagree, but

Re: [Openstack] server affinity

2011-03-02 Thread Eric Day
On Wed, Mar 02, 2011 at 09:48:27PM +, Jorge Williams wrote: On Mar 2, 2011, at 11:43 AM, Eric Day wrote: Now the arguments stated by many folks is that service_metadata is really instance properties or instance attributes and should instead be part of the instance object/record directly

Re: [Openstack] server affinity

2011-03-02 Thread Jorge Williams
On Mar 2, 2011, at 3:54 PM, Eric Day wrote: On Wed, Mar 02, 2011 at 09:48:27PM +, Jorge Williams wrote: On Mar 2, 2011, at 11:43 AM, Eric Day wrote: Now the arguments stated by many folks is that service_metadata is really instance properties or instance attributes and should instead be

Re: [Openstack] OpenStack Compute 1.1

2011-03-02 Thread Jorge Williams
https://launchpad.net/openstack-manuals On Mar 2, 2011, at 10:42 AM, Justin Santa Barbara wrote: Looks like some good changes. Where is this in launchpad, so the community can help develop it? For example, I'm willing to document the reservation of the aws: prefix. Justin On Wed, Mar 2,

Re: [Openstack] OpenStack Compute 1.1

2011-03-02 Thread Jorge Williams
I'd prefer the comments sections so that we have a reference when we discuss. But hey, I'll take suggestions from anywhere :-) -jOrGe W. On Mar 2, 2011, at 11:16 AM, Michael Mayo wrote: Should comments/suggestions go in this email thread or in the comments sections of the web help? I hate

Re: [Openstack] OpenStack Compute API for Cactus (critical!)

2011-03-02 Thread Devin Carlen
added a few inline On Mar 2, 2011, at 12:24 PM, Eric Day wrote: I havn't seen much activity on this, so though I'd do a quick brain dump of what I'm aware of: Auth/global: * Ability to lockout a user for some time period after failed auth. * Describe zones and regions (replaced with

Re: [Openstack] OpenStack Compute 1.1

2011-03-02 Thread Justin Santa Barbara
Thanks. Merge proposed :-) https://code.launchpad.net/~justin-fathomdb/openstack-manuals/doc-reserve-metadata-prefix/+merge/51974 Justin On Wed, Mar 2, 2011 at 2:16 PM, Jorge Williams jorge.willi...@rackspace.com wrote: https://launchpad.net/openstack-manuals On Mar 2, 2011, at 10:42

Re: [Openstack] OpenStack Compute 1.1

2011-03-02 Thread Justin Santa Barbara
Surely we should work on LaunchPad, just like the rest of the OpenStack deliverables? I just filed a merge proposal, so we'll see if this process works! On Wed, Mar 2, 2011 at 2:17 PM, Jorge Williams jorge.willi...@rackspace.com wrote: I'd prefer the comments sections so that we have a

Re: [Openstack] OpenStack Compute 1.1

2011-03-02 Thread Jorge Williams
Absolutely if you have changes to the doc make a merge proposal. I'm still getting used to the process, but I'll review. If you just want to discuss or make a suggestion or whatever use the comments section. -jOrGe W. On Mar 2, 2011, at 4:25 PM, Justin Santa Barbara wrote: Surely we should

Re: [Openstack] OpenStack Compute 1.1

2011-03-02 Thread Michael Mayo
I have no idea how to work with docbkx, and my suggestions/questions will be scattered throughout the API, so a merge probably wouldn't make sense in my case. I'm going to go with comments on WebHelp for now unless folks don't like that. Basically, I'm coming at this from an API

Re: [Openstack] OS API server password generation

2011-03-02 Thread Ed Leafe
On Mar 2, 2011, at 4:11 PM, Dan Prince wrote: We created a blueprint on adding support for password generation when creating servers. This is needed for Openstack API/Cloud Servers API v1.0 parity. We are anxious to get this work started so if you are interested please review the

Re: [Openstack] OS API server password generation

2011-03-02 Thread Justin Santa Barbara
I think we need the option _not_ to inject a password (e.g. if I'm on Linux and am going to use SSH private keys, or if I have another higher-security means of accessing my server) Does the API support this (yet)? Also, I know security through obscurity isn't really security, but if we're open

Re: [Openstack] OS API server password generation

2011-03-02 Thread Justin Santa Barbara
We should be secure out of the box, and not require the user to change their password or manually lock down SSH to disable password auth. A secure password would still be just as readable: I was thinking we'd use the secure bytes to generate a readable password (either using them as a seed or

Re: [Openstack] OS API server password generation

2011-03-02 Thread Mark Washenberger
Each time I call random.seed() on my box, it grabs another 256 bits from /dev/urandom (verified by strace). I feel like we can just rely on the old standby [random.choice(pwchars) for i in xrange(pwlength)], peppering a few random.seed() calls in periodically to skip onto a new pseudorandom

Re: [Openstack] OS API server password generation

2011-03-02 Thread Justin Santa Barbara
Why go to all this effort to promote bad code, when writing good code is just as easy? This is a fairly trivial fix we're talking about, probably comparable to the effort of running strace. Anyway, my focus is on users that don't want you setting passwords into their boxes (especially after

Re: [Openstack] OS API server password generation

2011-03-02 Thread Mark Washenberger
Yikes, I'm sorry. I didn't mean to give the impression of promoting bad code. I was coming at it from a simplicity perspective because I mistakenly thought my approach was cryptographically equivalent, assuming a case where the user does not want to skip password injection. To your main point,

Re: [Openstack] State of OpenStack Auth

2011-03-02 Thread Jesse Andrews
I agree that things should be pluggable, but OpenStack needs to have a default. Users need to know that they can point OpenStack client applications at OpenStack providers and it should work. I would prefer a signature based approach as the default (as signatures limits replay attacks;

Re: [Openstack] OS API server password generation

2011-03-02 Thread Justin Santa Barbara
On Wed, Mar 2, 2011 at 8:41 PM, Mark Washenberger mark.washenber...@rackspace.com wrote: Yikes, I'm sorry. I didn't mean to give the impression of promoting bad code. I was coming at it from a simplicity perspective because I mistakenly thought my approach was cryptographically equivalent,