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

2011-03-01 Thread Thierry Carrez
John Purrier wrote: Here is what we said on Feb 3 as the goal for Cactus: *OpenStack Compute API completed. We need to complete a working set of API's that are consistent and inclusive of all the exposed functionality . * This was not reflected in the Cactus plan at:

[Openstack] Reminder: OpenStack team meeting - 21:00 UTC

2011-03-01 Thread Thierry Carrez
Hello everyone, As a reminder, our weekly team meeting will take place at 21:00 UTC this Tuesday in #openstack-meeting on IRC. Apart from usual items, we'll discuss the go/nogo for 2011.1.1 release and python-novatools short term needs. Check out how that time translates for *your* timezone:

Re: [Openstack] server affinity

2011-03-01 Thread Sandy Walsh
Was just speaking with dabo about this and we agree that metadata is a bad name for this capability. I don't really care about what we call it, but metadata has some preconceived notions/meanings. Perhaps Criteria? Currently we have *some* criteria for creating a new instance on the Openstack

[Openstack] Automated tests

2011-03-01 Thread Soren Hansen
In case anyone is interested, I've put up the scripts I run from Hudson to do my automated testing: http://bazaar.launchpad.net/~linux2go/nova/jenkins-config/files Some of it is a series of more or less grotesque hacks, but it's been hugely helpful in my stabilisation work. The tests are

Re: [Openstack] How to deal with 'tangential' bugs?

2011-03-01 Thread Ewan Mellor
-Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 28 February 2011 20:02 To: Ewan Mellor Cc: Justin Santa Barbara; openstack@lists.launchpad.net Subject: Re: [Openstack] How to deal with 'tangential' bugs? On Mon, Feb 28, 2011 at 8:15 PM, Ewan Mellor

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

2011-03-01 Thread Jesse Andrews
pvo, Yep. I'm responding to the slide having 3 services, 5 endpoints (nova, glance, swift) Since the number of endpoints will depend on deployment configuration. And nova being a single repository doesn't mean it is a single service. Jesse On Mar 1, 2011, at 1:07 AM, Paul Voccio wrote:

Re: [Openstack] server affinity

2011-03-01 Thread Justin Santa Barbara
We decided in the merge to call it Metadata, despite being fully aware of the semantic issues, because that's what the CloudServers / OpenStack API uses. There are many better terms, but for the sake of avoiding a Tower of Babel, let's just call it Metadata. On Tue, Mar 1, 2011 at 6:56 AM,

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

2011-03-01 Thread Erik Carlin
Jesse - Understood they are separate within nova. We're just having a semantic disconnect which is my fault since I put the slides together in 3 min. Rackspace defines a standard service as having a clear api boundary of rest and optionally atom interfaces. In that model, nova is a service

[Openstack] State of OpenStack Auth

2011-03-01 Thread Eric Day
Hi everyone, I thought I'd take a moment to summarize the state of auth in the various OpenStack projects. With the recent discussion of OpenStack API auth in nova (bug+revert), how to structure accounts/users/projects/etc., and with Glance and Burrow needing auth solutions, now seems like a good

Re: [Openstack] State of OpenStack Auth

2011-03-01 Thread Soren Hansen
On a subject of authentication, I've always been puzzled why the token isn't just set as a standard http cookie? If it were, it would be dead simple to render a bit of HTML and interact with the API directly from a web server. The EC2 API can't do this because of the rather complex signature

Re: [Openstack] State of OpenStack Auth

2011-03-01 Thread Soren Hansen
2011/3/1 Eric Day e...@oddments.org: Well, hopefully with a shared, modular service, we can add a token module that uses cookies instead. :) Sure :) I was just hoping to extract whatever wisdom might have been behind the decision to seemingly reinvent the concept of cookies. Perhaps there's

Re: [Openstack] Entities in OpenStack Auth

2011-03-01 Thread Monsyne Dragon
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

Re: [Openstack] Entities in OpenStack Auth

2011-03-01 Thread Justin Santa Barbara
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

Re: [Openstack] Entities in OpenStack Auth

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

Re: [Openstack] Entities in OpenStack Auth

2011-03-01 Thread Justin Santa Barbara
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

Re: [Openstack] Entities in OpenStack Auth

2011-03-01 Thread Paul Voccio
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: