Hi Glen,
I've read through the wiki page and although I think the individual
commands are worthy commands to add to the API, I don't see why this
is all being bunched into (yet another) API. I think if you broke out
these commands into individual blueprints:
* Contributors could have already
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
On Thu, Mar 3, 2011 at 11:06 AM, Brian Lamar brian.la...@rackspace.com wrote:
Part of the API specification says that the OpenStack API supports gzip
compression in requests and responses. I have an extremely simple WSGI
middleware implementation of this finished, but it does not support
Does anyone else feel it's a bit late to be targeting new blueprints
for Cactus since we're 2 weeks from branch merge proposal freeze?
http://wiki.openstack.org/CactusReleaseSchedule
-jay
On Wed, Mar 2, 2011 at 4:11 PM, Dan Prince dan.pri...@rackspace.com wrote:
We created a blueprint on
Hi Jay,
Would it be better to have stuff like this go into a bug report? For that
matter should anything that helps us reach parity with the Cloud Servers v1.0
spec be a bug report or a blueprint?
I like the dependency graphs we get with Blueprint's as it helps track how
close we are to
Thanks, Jay ‹ I'll take your suggestion and break these up; in fact, we
were planning on doing that as the next step, and we have a team here at
Rackspace that's planning on working on them. We plan on implementing
these using the 1.1 extensions mechanism initially, and thus are not
planning on
On Thu, Mar 3, 2011 at 3:33 PM, Michael Mayo m...@openstack.org wrote:
Here are my thoughts, as a client developer:
1. Hit auth server first for token, then hit compute and storage endpoints
This is fairly simple, but there are a couple of problems with it:
a. It's not very curl or browser
On Thu, Mar 3, 2011 at 3:59 PM, Michael Mayo m...@openstack.org wrote:
I was thinking more of a sniff someone's traffic and perform those same
requests again sort of attack. But then again, I'm an iPhone guy and not a
security expert :)
In the end, I'm simply advocating that we reduce the
On Mar 4, 2011, at 10:29 AM, Jay Pipes wrote:
Would the best option be if the OpenStack API supported both auth
mechanisms (signature, basic HTTP) and allowed the deployers to pick
which ones were best for which clients? For instance, if OpenStack
supported both auth mechanisms
On Thu, Mar 3, 2011 at 12:20 PM, Eric Day e...@oddments.org wrote:
We should support old versions. The API layers should be a very thin
layer over what the Nova internal API provides, so even if we have
v1.0, v1.1, etc. subdirectories in the API and do full code copying,
it should be a fairly
But, unless I'm mistaken, there is only a single call to the auth
server on the first request. If we go with a Swift model (which is
similar to the proposed solution from Vish and Andy, but not quite the
same), the auth server returns the storage-management-url after
authenticating the
On Mar 4, 2011, at 11:05, Jorge Williams jorge.willi...@rackspace.com wrote:
though we removed the details of this part at the request of the swift team.
Khaled implement this code to support both the default auth component and
to integrate the blueprint with swift. The response to
On Fri, Mar 4, 2011 at 10:50 AM, Dan Prince dan.pri...@rackspace.com wrote:
Hi Jay,
Would it be better to have stuff like this go into a bug report? For that
matter should anything that helps us reach parity with the Cloud Servers v1.0
spec be a bug report or a blueprint?
No, blueprint is
As Brian is temporarily out of the office, I'll answer for him. Here are a few
(major-version) differences I see in the 1.1 spec:
1) marker keyword replaces offset for pagination (functionally different, not
just a different name)
2) server addresses container structured differently
3) all
On Fri, Mar 4, 2011 at 1:33 PM, Brian Waldon brian.wal...@rackspace.com wrote:
As Brian is temporarily out of the office, I'll answer for him. Here are a
few (major-version) differences I see in the 1.1 spec:
OK. Either Brian is good ;)
1) marker keyword replaces offset for pagination
On Mar 4, 2011, at 12:09 PM, Greg wrote:
On Mar 4, 2011, at 11:05, Jorge Williams jorge.willi...@rackspace.com wrote:
though we removed the details of this part at the request of the swift team.
Khaled implement this code to support both the default auth component
and to integrate
On Mar 4, 2011, at 1:25 PM, Jorge Williams wrote:
I don't want this to deteriorate into a flame war but let's get our facts
straight:
1) It completely integrated with the existing auth system and it integrated
with our default Auth component.
2) All tests passed. I was looking over
All this talk about auth and making the API easy for developers to use got me
thinking.
The two most popular formats for APIs are XML and JSON.
XML is language neutral and sort of painful to read by a human. And writing an
XML parser sucks. It's not hard, but it's time consuming and
While a middleware solution for the limited functionality would technically
work, I think most of us would agree it should not be implemented as
middleware. It can be done much more efficiently at the datastore level,
especially with the introduction of marker.
As for shared_ip_groups, I
I think, really, we are getting off on a tangent here. The purpose of
multitenant is to have a label ('account' or 'project' or whatever )
that we tag resources (instances, etc) in nova with so that we can group
together usage reports, etc, that go to some system outside of openstack
On Fri, Mar 4, 2011 at 2:55 PM, Brian Waldon brian.wal...@rackspace.com wrote:
While a middleware solution for the limited functionality would
technically work, I think most of us would agree it should not be
implemented as middleware. It can be done much more efficiently at the
datastore
21 matches
Mail list logo
