Format wars are so tiring. What formats we Openstack should output is a
marketing question, not a technical one. We should be trying to figure
out how to do more formats, not fewer, because customers don't want us
making choices that place constraints on them, especially when those are
tied to
On Jun 4, 2011, at 9:14 AM, Ed Leafe ed.le...@rackspace.com wrote:
On Jun 3, 2011, at 1:13 PM, Bryan Taylor wrote:
We've standardized on XML for backend work. We aren't spending much time
debugging serialization issues and are pretty happy with our decision and
aren't likly to change any
Motto!
On 6/4/11 9:39 PM, Joshua McKenty j...@piston.cc wrote:
Damn, I knew I should have trademarked the OpenStack, Cloud's Big Tent
slogan!
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe :
I am not feeling well today so i'm going to take ETO.
Sent from my iPhone
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help :
Doh! Sorry for the spam openstack. o now autocompletes to this instead
of my project team's list and I didn't notice.
On 6/9/11 12:02 PM, Ken Savich ken.sav...@rackspace.com wrote:
You sent that to the openstack list
On Jun 9, 2011, at 11:55 AM, Bryan Taylor btay...@rackspace.com wrote:
I'm
I'm reading through the dev guide for the first time. I hope my comments are
timely.
I'm glad to see section 2 begin by defining concepts. I'd suggest adding all
these concepts to the openstack glossary at http://wiki.openstack.org/Glossary.
The github site for keystone defines these concepts
that are accessible outside the internal network and it has been a deal breaker
for many such systems.
From: Ziad Sawalha
ziad.sawa...@rackspace.commailto:ziad.sawa...@rackspace.com
Date: Tue, 21 Jun 2011 23:49:28 -0500
To: Bryan Taylor btay...@rackspace.commailto:btay...@rackspace.com,
openstack
If we use something other than 80 for http and/or 443 for https, then
clients will have to know magic numbers for the port and firewall
obstacles will annoy them. I don't see HTTP as something we just happen to
have chosen. We should prefer convention over configuration, and embrace
the
to get to that outcome,
including specifying it in the server configuration, or running behind
load balancers or other front-end services. Running everything be
default on different ports by default has little bearing on how it
gets run in production.
On Sun, Jun 26, 2011 at 12:50 PM, Bryan Taylor
What if we wrote our own spec of the common features. Document the heck
out of anything where the amazon spec and implementation differ and follow
the implementation. Do to amazon what WS-I did to SOAP tools. Any fraction
of the market we can get perceiving value in the true interoperability
spec
But this cuts both ways: many of their clients don't immediately adopt new
changes, and if we can provide a spec for what parts of the amazon api you
have to stay within to obtain switch-ability with openstack, then we slow
down the adoption of those new features.
The clients that are happy with
How is this different in effect than letting swift or nova be tenants?
Each tenant gets to define users, roles, and groups, right?
On 07/13/2011 10:39 AM, Jay Pipes wrote:
On Wed, Jul 13, 2011 at 12:45 AM, Ziad Sawalha
ziad.sawa...@rackspace.com wrote:
Here's a possible use case we can
On 8/26/11 1:19 PM, Devin Carlen devin.car...@gmail.com wrote:
There have been a lot of efforts lately to bring the feature set of the
OpenStack API in line with the EC2 API, and this is admirable. But this
has NOT been happening at the architect level. This has been happening
at the
I propose identifying tokens by their full keystone URI within X-Auth-Token
header. EG: instead of
X-Auth-Token: fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
we would do
X-Auth-Token:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
This has the advantage of allowing
, it *might* make
sense to define keystone-token as a link relation
http://tools.ietf.org/html/rfc5988, giving you:
Link:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
rel=keystone-token
On 04/09/2011, at 2:39 AM, Bryan Taylor wrote:
I propose identifying tokens
-User and
Keystone-Tenant which could also be used in Vary Headers.
On 9/4/11 8:06 PM, Bryan Taylor btay...@rackspace.com wrote:
Love it.
Link:
https://keystone.server/tokens/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
rel=keystone-token
Fixed: s/tenants/tokens/ (my bad).
On 9/4/11 7:40 PM, Mark
Nottingham m...@mnot.net wrote:
Good point; Link makes more sense on a response.
Cheers,
On 05/09/2011, at 12:49 PM, Bryan Taylor wrote:
Hmmm, I'm thinking more about this. Would using the Link: header break
the
ability to use the Vary header? I can't Vary on a Link header based on
it's rel
I'm working on an incident system that my company, as an OpenStack operator,
will use to support our deployment of OpenStack. Our first features all involve
outside tools creating incidents, but It seems like it would be beneficial to
define a standard incident API so that core openstack
An incident is a form of ticket that recognizes that an existing
requirement (customer or internal) isn't being met.
On 09/07/2011 06:20 AM, Soren Hansen wrote:
2011/9/7 Bryan Taylorbtay...@rackspace.com:
I'm working on an incident system that my company, as an OpenStack operator,
will use to
I'm skeptical, because usually ticket creation has to be a two way
interaction because the entity asking for the ticket has to know that it
succeeded end to end and should receive a URI back so that they can
record it.
There should be a well defined API that forms the boundary between
On 09/07/2011 02:55 PM, Monsyne Dragon wrote:
Presumably you mean creating a support ticket when an error condition is
reported by OpenStack?
For Nova (compute) we have a notification api that reports various conditions.
Yes.
Nova itself would not interface with a ticketing (aka incident
I agree with Jorge, HTTP defines PUT and POST in a way that allows each
to be used for both create and update. We should not be changing the
semantics of HTTP's uniform interface by adding additional constraints
that are not documented in the HTTP spec.
On 09/19/2011 11:33 PM, Jorge Williams
The etherpad thing is already somewhat hard to read. I wonder if we
could try first to simply get a list of topics that we want guidelines
on without first trying to say what the standard is. My experience
trying to come up with such standards internally is that they will
generate a huge
That's an impressive list. I haven't heard of half of them, which answers
your question.
On 9/27/11 5:47 PM, John Dickinson m...@not.mn wrote:
What benefits does an openstack-satellite project bring? Other than all
using some openstack component, what do these projects have in common
that
) is about a place to
centralize code for various projects that consume openstack core projects.
To be clear, no one is arguing against promoting a diverse openstack
ecosystem (or a way to find what's in that ecosystem).
--John
On Sep 27, 2011, at 10:51 PM, Bryan Taylor wrote:
That's
Another possiblity here would be to support satellite contributors with
some kind of continuous integration against the development branches of
openstack components. We would uprev and deploy new codebases of
openstack and let registered satellite projects integrate against the
latest code
on to spec-specific
details.
Thanks for the great input, guys!
Waldon
On Oct 11, 2011, at 2:12 AM, Bryan Taylor wrote:
On 10/11/2011 12:26 AM, Mark Nottingham wrote:
Where would these versions show up? In URLs? In documentation? In
response payloads?
If they show up in URLs, then every
On 10/11/2011 10:27 AM, George Reese wrote:
Yes, my proposed solution requires OpenStack implementations to support ALL
major versions of ALL APIs. That's absolutely critical for building a healthy
ecosystem.
That may be completely impossible if different versions require
incompatible
On 10/11/2011 09:02 PM, Mark Nottingham wrote:
Linear versioning is of very limited use.
If OpenStack wants to keep a clear definition of what the OpenStack CORE
is, then this needs to evolve linearly (austin, bexar, cactus, diablo,
essex, etc...). I think you could make an argument that this
On 10/11/2011 09:08 AM, Mark McLoughlin wrote:
Btw, which APIs are we talking about here? Just compute and storage. Or
image and identity too?
I think this should be much broader and include any API contributed to
the OpenStack banner, including those in the OpenStack Satellite.
This email
On 10/11/2011 10:28 AM, George Reese wrote:
It's wildly inappropriate to equate a thing with its representation.
Unless the thing is itself a representation, yes. A resource can be ANYTHING: a
server, a database record about a server, a car, a rock, the concept of love,
the act of smiling, or
On 10/12/2011 07:55 PM, Mark Nottingham wrote:
The duplication of effort can be solved by having an intermediary do the translation. Repose already does this.
That's where there be dragons. Inferring that the user wants to go to version N of the
I don't know, but there are several obvious next steps:
- Document publicly the criteria for a project to fit
- Identify resources available to participating projects
- Formalize it with the PPB and unleash it
- Build the Satellite community
A big question we didn't discuss is what the
On 10/14/2011 04:52 PM, Jay Pipes wrote:
On Fri, Oct 14, 2011 at 3:22 PM, Bryan Taylor btay...@rackspace.com wrote:
I don't know, but there are several obvious next steps:
- Document publicly the criteria for a project to fit
Not really sure
On 10/15/2011 07:58 AM, Jay Pipes wrote:
There is a well-defined trademark policy for OpenStack:
http://www.openstack.org/brand/openstack-trademark-policy/
What is being used for OpenStack Satellite is simply the Word Mark,
which is liberally applied to refer to the OpenStack project
On 10/24/2011 11:20 PM, Mark Nottingham wrote:
tl;dr
Much omitted, since it's long... I agree strongly with 98% of what you are
saying.
I'll focus on the variants here. I'd rather just get rid of them.
GET /servers.v1.json
vs
http://api.example.com/v1/foo
I agree with you that the latter
On 10/26/2011 04:45 PM, Jorge Williams wrote:
On Oct 26, 2011, at 1:19 PM, Bryan Taylor wrote:
So no pdfs or excel spreadsheets without conneg.
But PDFs and excel spreadsheets are precisely why you want variants!
Reports and spreadsheets are presentation layer resources that should
come
On 10/26/2011 11:19 PM, Mark Nottingham wrote:
My problem with indicating the media type versioning in the root of the URI is that /v1/ style URIs typically indicate the versioning of the *whole* API, not just the media types being used.
To be completely honest, I'd
On 10/26/2011 11:19 PM, Mark Nottingham wrote:
To be truly RESTful at the level of the Fielding article (which I
actually think is the best description of HATEOAS there is) you
shouldn't have these variants at all. I worry about us trying to
put lipstick on the pig -- all these variants are a
On 10/27/2011 08:56 AM, George Reese wrote:
THE API SHOULD NOT BE SERVING ATOM CONTENT!!!
What!? Atom is a fine way to represent a collection. Especially one that
is append only.
There's a nasty habit within the OpenStack community of trying to boil
the ocean. And here we are navel gazing
On 10/27/2011 10:36 AM, George Reese wrote:
#3 Push scales a hell of a lot better than having tools polling a cloud
constantly. It doesn't matter whether it is polling the API, polling a
feed, or polling a message queue. Polling is one of the most unscalable
things you can do in any distributed
Just to be clear we are talking about APIs fit for customer consumption
here, not internal integrations where both ends are under our control.
On 10/27/2011 11:38 AM, George Reese wrote:
I disagree. The web was designed specifically to solve the distributed scaling
problem and it's based on
On 10/27/2011 05:52 PM, Mark Nottingham wrote:
Generating WADL (or anything else) from code is fine, as long as we have the
processes / tools (e.g., CI) in place to assure that a trivial code change
doesn't make a backwards-incompatible change in what we expose to clients.
You bring up a
The keystone management API has a validate token method that looks like:
GET /tokens/{tokenId}?belongsTo=tenantId
See
http://docs.openstack.org/incubation/identity-dev-guide/content/Validate_Token-d1e1914.html
Why is the validate token method in the keystone admin API and not the service
API?
Generally, I like the new versioning proposal and see it as simpler. If
Compute adopts this change and succeeds with it, I'd like to see it
OpenStack wide. Clients shouldn't have to learn several different
versioning schemes.
My 2 cents on your questions:
On 12/20/2011 09:35 AM, Brian
On 12/21/2011 05:02 AM, Monty Taylor wrote:
On 12/20/2011 07:00 PM, Bryan Taylor wrote:
Version APIs for compatability, not release tracking.
I could not agree with this more strongly. Like, really, really, really
strongly.
Strong feelings are not a technical reason.
Clients should
couple
On 12/21/2011 05:56 AM, Mark McLoughlin wrote:
On Tue, 2011-12-20 at 10:35 -0500, Brian Waldon wrote:
- Versioning is important, but I'd prefer us to place more emphasis
on how to design the API such that we can continue to expand the
API in compatible ways for a decent period
47 matches
Mail list logo
