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:
http://wiki.openstack
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:
htt
+1
From: Dan Prince [dan.pri...@rackspace.com]
Sent: Monday, February 28, 2011 4:20 PM
If you really need to write a test case ahead of time (perhaps even to make
your case that a bug exists) why not just create a launchpad bug and then
attach the test case as a
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
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 not
> -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
> w
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:
>
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, Sand
Are we using the name metadata to describe a different feature than the one
that exists in the CloudServers api?
It seems like a different feature for the user-properties metadata to have
meaning to the api other than "store this information so I can read it later".
"Justin Santa Barbara" said
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
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
2011/3/1 Eric Day :
> Signature based auth such as EC2 should also always require
> 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).
Just a note: The request also includes a tim
On Tue, Mar 01, 2011 at 09:47:00PM +0100, Soren Hansen wrote:
> 2011/3/1 Eric Day :
> > Signature based auth such as EC2 should also always require
> > 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
> >
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 mecha
On 3/1/11 2:53 PM, Soren Hansen wrote:
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 beca
Well, hopefully with a shared, modular service, we can add a token
module that uses cookies instead. :)
-Eric
On Tue, Mar 01, 2011 at 09:53:36PM +0100, Soren Hansen wrote:
> On a subject of authentication, I've always been puzzled why the token
> isn't just set as a standard http cookie?
>
> If
2011/3/1 Eric Day :
> 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 some reason to avoi
On Tue, Mar 01, 2011 at 10:02:37PM +0100, Soren Hansen wrote:
> 2011/3/1 Eric Day :
> > 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 seem
Hi everyone,
I'd like to build off the last auth thread about where the various
auth components are today and now look at what types of entities they
manage. Right now only Swift and Nova have entities, so only those
will be mentioned.
Swift
Swift has the concept of accounts, users, and groups.
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
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 requ
On 3/1/11 6:32 PM, Justin Santa Barbara wrote:
Won't putting this in the URL both:
1) Break CloudServers API compatibility (a total no-no)?
and
No. The value is added to the server management url that is reported
when you login. This is how the current Rackspace cloudservers API
handles this.
On Tue, Mar 01, 2011 at 06:46:21PM -0600, Monsyne Dragon wrote:
> 1) Break CloudServers API compatibility (a total no-no)?
> and
>
>No. The value is added to the server management url that is reported when
>you login. This is how the current Rackspace cloudservers API handles
>
Here's how I understand it. Suppose my username is justin and I'm a member
of 3 projects: project1, project2 and project3
1. If I log in using the v1.0 API, I hit auth.openstack.org/v1.0 and I
get X-Server-Management-Url: nova.openstack.org/v1.0/justin.
2. Presumably that does a 'join ac
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
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
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
Thanks Eric. That actually makes a lot of sense to me, and seems to tally
with my understanding of the auth sequence for v1.0 and v1.1
and compatibility behavior for v1.0 as I described it.
I think my personal preference would be not to pass the project this way,
because it's another "special-cas
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" 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
>
29 matches
Mail list logo
