Re: [Openstack] [Doc] Talk shop: API Docs

We are outside by the bell at the top of the stairs. Sent from my Motorola Smartphone on the Now Network from Sprint! -Original message- From: thingee To: Anne Gentle Cc: "openstack@lists.launchpad.net" Sent: Tue, Apr 16, 2013 15:23:37 PDT Subject: Re: [Openstack] [Doc] Talk shop: API

Re: [Openstack] Do we have any schema for keystone v3.0 request/responses

I was waiting for things to stabilize. Give me the go ahead Joe and I'll update and submit. Sent from my Motorola Smartphone on the Now Network from Sprint! -Original message- From: heckj To: "Ali, Haneef" Cc: "openstack@lists.launchpad.net" Sent: Wed, Dec 5, 2012 18:32:03 CST Subjec

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

need the server to do that additional validation for you. Right. -Dolph On Thu, Nov 15, 2012 at 8:20 AM, Jorge Williams mailto:jorge.willi...@rackspace.com>> wrote: No, it's optional. Token validation returns what it normally does. The only thing belongs to does is that you fai

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

mandatory? If not, what will token validation API return? > > {"access": [list of tokens]} > > ? > > > Guang > > > -Original Message- > From: Jorge Williams [mailto:jorge.willi...@rackspace.com] > Sent: Wednesday, November 14, 2012

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

t;> >>> Thanks, >>> joe >>> >>> -----Original Message- >>> From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net >>> [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On >>> Behalf Of heckj >&

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

t; unscoped token? Surely they will have the same scope won't they? In >>>>> which case there is no need for both concepts. >>>> >>>> let's compare with Kerberos: In my view an unscoped token is >>>> comparaable with a ticket granting

Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

I'm okay with "Starting Tokens". -jOrGe W. On Oct 23, 2012, at 7:25 AM, Adam Young wrote: On 10/23/2012 01:25 AM, Jorge Williams wrote: Here's my view: On making the default token a configuration option: Like the idea. Disabling the option by default. That's fine

Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

Are you guys +1 ing the original Idea, my suggestion to make it optional, the fact that I think we should call these sloppy tokens? On 10/22/2012 03:40 PM, Jorge Williams wrote: +1 here too. At the end of the day, we'd like the identity API to be flexible enough to allow the token to be

Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

+1 here too. At the end of the day, we'd like the identity API to be flexible enough to allow the token to be scoped in a manner that the deployer sees fit. What the keystone implementation does by default is a different matter -- and disabling multiple tenant scope by default would be fine b

Re: [Openstack] [keystone] Rate limit middleware

More info on the Repose rate limiter here: http://wiki.openrepose.org/display/REPOSE/Rate+Limiting+Filter The rate limiter has the concept of limit groups -- you can specify rate limits for a particular group -- then introspect the request to see which group applies. Typically a user can be pl

Re: [Openstack] WADL [was: v3 API draft (update and questions to the community)]

All of the XSDs produced so far use XSD 1.1. -jOrGe W. On Jun 15, 2012, at 8:57 AM, Christopher B Ferris wrote: +1 Over-reliance on WADL will only make it more challenging to gracefully evolve the APIs such that implementations can be forwards and/or backwards compatible, especially when exc

Re: [Openstack] WADL [was: v3 API draft (update and questions to the community)]

Totally agree. Note that we are using WADL today to create documentation artifacts. So http://api.openstack.org/ is generated from WADLs as are good chunks of the books on http://docs.openstack.org/. We're also using WADL for validation and testing at Rackspace internally, and I'm sure othe

Re: [Openstack] Nova API Specification

On May 30, 2012, at 8:33 AM, Day, Phil wrote: Hi Folks, I was looking for the full definition of the API requests, and I’m a tad confused by what I find here: http://api.openstack.org/ Specifically for Server Create there is both and “Server – Create” and “Server – Extended Create”, although

Re: [Openstack] Keystone service catalogue has non-core services?

Hey Liem, We had a brief conversation about this at the summit. Ec2 and volume are core services not extension services -- this was described in a wiki somewhere. Carlos has gone through the contracts cleaned them up and updated them to reflect reality -- and they include this particular cha

Re: [Openstack] Just JSON, and extensibility

On Apr 13, 2012, at 3:20 PM, Justin Santa Barbara wrote: My understanding is that the solution we have now is that any extension goes into its own namespace; we assign a prefix to the namespace and have a way to map that prefix to the full namespace. (Similar to XML schemas). Currently prefi

Re: [Openstack] Just JSON, and extensibility

On Apr 13, 2012, at 8:47 AM, Mark Nottingham wrote: > [ Full disclosure -- I'm using my personal address with Launchpad, etc., but > I work for Rackspace. ] > > On 12/04/2012, at 7:28 PM, Jorge Williams wrote: > >> Generally, I agree with a lot of what you're

Re: [Openstack] Image API v2 Draft 4

Generally, I agree with a lot of what you're saying, but I want to point out a couple of things: 1. Static language folks gravitate to XML, not simply because they're invested in it, but because it solves a real problem: In a static language, I want to to say something like: myServer.name = "

Re: [Openstack] Image API v2 Draft 4

I'm also a strong supporter of XML. XML does a good job of lowering barriers for a key group of clients, specifically those that work with statically typed languages. It offers key benefits in terms of extensibility and validation. I'd hate to lose it. -jOrGe W. On Apr 10, 2012, at 12:57 PM,

Re: [Openstack] Image API v2 Draft 4

On Apr 9, 2012, at 6:03 PM, Justin Santa Barbara wrote: How about we discuss this further at the summit :-) I think that's a sensible proposal. We're not likely to reach a good conclusion here. I think my viewpoint is that even json-dressed-as-xml is fine; no end-user gives two hoots what ou

Re: [Openstack] Image API v2 Draft 4

Justin, >From a JAX-RS / Java persecutive, starting with an XML schema and having that >dictate what the JSON will look like -- doesn't just make sense -- it makes >life *A LOT* easier. And a lot of services written in Java do just that. >Unfortunately, as you pointed out, this approach has

Re: [Openstack] OpenStack Java API

Some thoughts, Using the binding to generate WADLs and XSDs would definitely be useful -- especially since a lot of the extensions are currently undocumented. Certainly we can use these as a starting point for our documentation efforts. Keep in mind, though, that extensions are optional and th

Re: [Openstack] Keystone: is revoke token API "officially" supported

ws mailto:dolph.math...@gmail.com>> Date: Thu, 26 Jan 2012 17:17:12 -0600 To: Ziad Sawalha mailto:ziad.sawa...@rackspace.com>> Cc: Jorge Williams mailto:jorge.willi...@rackspace.com>>, Dolph Mathews mailto:dolph.math...@gmail.com>>, "Yee, Guang" mailto:guang@hp.c

Re: [Openstack] Keystone: is revoke token API "officially" supported

nly be adding a new method on an existing resource, so would not require complex naming changes… Open to alternative points of view.. Z From: Jorge Williams mailto:jorge.willi...@rackspace.com>> Date: Thu, 26 Jan 2012 13:36:13 -0600 To: Dolph Mathews mailto:dolph.math...@gmail.com>>

Re: [Openstack] Keystone: is revoke token API "officially" supported

xtension like this. I'd still lean towards the "correct" practice of adding this as another extension. Especially since that extension would only be adding a new method on an existing resource, so would not require complex naming changes… Open to alternative poin

Re: [Openstack] Keystone: is revoke token API "officially" supported

Moving it to an extension makes sense to me. Ziad, does it make sense to add it to OS-KSADM...or is this a different extension all together...revoke token extension? -jOrGe W. On Jan 26, 2012, at 11:43 AM, Dolph Mathews wrote: It is definitely not a documented call (hence the "should this be

Re: [Openstack] WADL for compute API v1.1

I don't think that it would be too nasty given the way that Anne has structured: https://github.com/openstack/compute-api Where we have a different directory for each version of the API. -jOrGe W. On Jan 25, 2012, at 10:30 AM, Eoghan Glynn wrote: > > >> So I was wondering whether there was a

Re: [Openstack] WADL for compute API v1.1

They should point to the correct links. I believe that the PDFs and WADL are published on docs.openstack.org, and the links should point to the artifacts there. Or you can do what keystone is doing and host the stuff locally. -jOrGe W. On Jan 25, 2012, at 10:08 AM, Eoghan Glynn wrote: > >

Re: [Openstack] Supporting start/stop compute api from OpenStack API

Tomoe, Once you get the extension up and running you'd want to document it :-) There are a set of templates for documenting the extension here: https://github.com/RackerWilliams/extension-doc-templates More (high level) details on API extensions here: http://docs.rackspace.com/openstack-extens

Re: [Openstack] Configure Rate limits on OS API

Hi Blake, Repose is capable of rate limiting based on group. It also supports querying limits and maintaining the limits consistent even as nodes are scaled horizontally. You can find the code on git hub: https://github.com/rackspace/repose Here's the presentation I gave on the subject on Es

Re: [Openstack] Automatically confirmed after 24 hours on Resize API

I'm with Waldon on this. This is a spec...the implementation hasnt caught up. Sent from my Motorola Smartphone on the Now Network from Sprint! -Original message- From: Brian Waldon To: Anne Gentle Cc: "openstack@lists.launchpad.net" Sent: Tue, Dec 27, 2011 10:20:30 CST Subject: Re:

Re: [Openstack] Extension Documentation

for integration are >>> welcomed. >>> 8. We need a discussion about who will review these extension >>> submissions and ensure they get built. >>> >>> Based on the struggle to get these docs written, I also want to know >>> if you all find the t

Re: [Openstack] Extension Documentation

Inline: -Original Message- From: Anne Gentle Date: Fri, 9 Dec 2011 08:17:15 -0600 To: Jorge Williams Cc: "openstack@lists.launchpad.net (openstack@lists.launchpad.net)" Subject: Re: [Openstack] Extension Documentation >Hi everyone - >Overall I support this effort and h

[Openstack] Extension Documentation

Hi All, I've started putting together a site to hold extension documentation. You can see it here: http://docs.rackspace.com/openstack-extensions/ The idea is to have a repository for all extensions, whether the extension is an OpenStack extension or a vendor specific extension. It makes sen

Re: [Openstack] OSAPI and Zones

Inline: On Nov 15, 2011, at 3:36 AM, Doude wrote: > Thanks a lot for your answers. > > But why do you want to move the Zone code into the extension part ? > It's a core part of OpenStack, why it doesn't stay in the core code ? If something is in core then it's guaranteed to be available always.

Re: [Openstack] describing APIs for OpenStack consumers

The core API WADL is here: https://github.com/openstack/compute-api/blob/master/openstack-compute-api-1.1/src/os-compute-1.1.wadl Keystone also has a number of WADLs here: https://github.com/openstack/keystone/tree/master/keystone/content -jOrGe W. On Nov 14, 2011, at 2:21 PM, Rupak Ganguly wr

Re: [Openstack] OSAPI and Zones

Last time I had a conversation about this, I believe the goal was to refractor and document Zone support as an extension to the core API. We're just not there yet. -jOrGe W. On Nov 14, 2011, at 9:49 AM, Doude wrote: > Hi all, > > I'm trying to understand the multi-zone architecture of OpenSt

Re: [Openstack] Nova-API Team Meeting Notes

Thoughts on v1.1 -> v2 rename. 1. As stated: URI changes /v1.1/ to /v2/ though we keep redirecting 1.1 requests to v2.0. 2. Mime type accepts version=2 as a parameter but still responds to version=1.1 so the following will remain valid mimeTypes: a) application/vnd.openstack.compute+x

Re: [Openstack] Push vs Polling (from Versioning Thread)

Huh? I didn't write that. George did. On Oct 28, 2011, at 11:35 AM, Caitlin Bestler wrote: > Jorge Williams wrote: > >> Push notifications don't make your core system any more complex. You push >> the change to a message queue and rely on another system to do the

Re: [Openstack] Push vs Polling (from Versioning Thread)

On Oct 28, 2011, at 10:33 AM, George Reese wrote: > You are describing an all-purpose system, not one that supports the narrow > needs of IaaS state notifications. > > There's no reason in this scenario to guarantee message delivery. Like I said, there are a lot of factors to consider. And

Re: [Openstack] Push vs Polling (from Versioning Thread)

On Oct 28, 2011, at 8:11 AM, George Reese wrote: Push notifications don't make your core system any more complex. You push the change to a message queue and rely on another system to do the work. The other system is scalable. It has no need to be stateless and can be run in an on-demand format

Re: [Openstack] +1, All services should have WADLs

oal isn't to make, parse, or manually read WADL's - it's to make this set of web pages. If WADL helps me get there expediently, I'm all over it. -joe On Oct 27, 2011, at 11:03 AM, Jorge Williams wrote: As I stated in previous emails, we are pulling data from the WADL t

Re: [Openstack] +1, All services should have WADLs

As I stated in previous emails, we are pulling data from the WADL to grab human-consumable REST API docs that live at docs.openstack.org today. We can certainly expand that capability to create a unified API documentation set rather than individual guides. A lot of

Re: [Openstack] API Versioning and Extensibility

On Oct 27, 2011, at 8:56 AM, George Reese wrote: On Oct 27, 2011, at 8:11 AM, Jorge Williams wrote: Response inline: On Oct 27, 2011, at 12:50 AM, Bryan Taylor wrote: 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

Re: [Openstack] API Versioning and Extensibility

Response inline: On Oct 27, 2011, at 12:50 AM, Bryan Taylor wrote: > 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 exc

Re: [Openstack] API Versioning and Extensibility

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! "Here's my usage stats for 2009... http://usage.api.acme.com/v1.0/jorgew/2009/usage.pdf"; You mean to tell me that I can't sen

Re: [Openstack] +1, All services should have WADLs

++Totally agree with that approach. Looking forward to looking over the Images 2.0 API :-) -jOrGe W. On Oct 26, 2011, at 10:23 AM, Jay Pipes wrote: > On Wed, Oct 26, 2011 at 1:06 AM, Mellquist, Peter > wrote: >> The topic of when an API should be defined is also important. Do we define >> an

Re: [Openstack] +1, All services should have WADLs

I don't mind generating a WADL so long as we have a good expressive tool for doing so. I haven't found one yet. There was a project a while back for doing so called "Rest Described and Compile" that seemed to be heading in the right direction, but it hasn't been worked on in a while. http://to

Re: [Openstack] describing APIs for OpenStack consumers

The WADL should be complete for Nova. There are a couple of error fixes that I've completed but haven't pushed up yet. I'll try to get to those tomorrow and I'll look over Nachi's contributions as well. What's not done in Nova is documenting all of the extensions. I'm working on that and wil

Re: [Openstack] describing APIs for OpenStack consumers

00 lines script. > > I used lxml.objectify > http://lxml.de/objectify.html > > You can read wadl as python object. > It is very easy to generate something from the WADL if you know WADL > structures. > > xsd_root = objectify.parse("PATH2WADL").getroot() > x

Re: [Openstack] describing APIs for OpenStack consumers

Totally agree. The goal is to create narrative documents that devs can read etc. The WADL is just there to fill in the nitty gritty details in a consistent way. -jOrGe W. On Oct 25, 2011, at 5:34 PM, Caitlin Bestler wrote: WADL sounds like a wonderful validation tool. But shouldn’t our prim

Re: [Openstack] describing APIs for OpenStack consumers

: Which dev docs and how? I haven't spotted those scripts or systems... -joe On Oct 25, 2011, at 2:58 PM, Jorge Williams wrote: Some of that dev guide documentation is generated from a WADL :-) The purpose of a WADL is that it is machine readable so it opens up a lot of possibili

Re: [Openstack] describing APIs for OpenStack consumers

Some of that dev guide documentation is generated from a WADL :-) The purpose of a WADL is that it is machine readable so it opens up a lot of possibilities, for creating docs, testing, validation, etc. -jOrGe W. On Oct 25, 2011, at 4:14 PM, Daryl Walleck wrote: Hi everyone, This is just my

Re: [Openstack] describing APIs for OpenStack consumers

Hi Nati, I've actually fixed some of the issues you're describing but haven't had a chance to check these in. Let's talk about the issues you're seeing off line and combine our efforts. -jOrGe W. On Oct 25, 2011, at 3:52 PM, Nati Ueno wrote: > Hi Joe, Anne > > I'm working on WADL of Openst

Re: [Openstack] describing APIs for OpenStack consumers

We've done quite a bit of work to get high quality documentation from a WADL, in fact we are using some of this today. We've taken most of the hard work re: parsing the WADL, at least for the purpose of generating docs from it and of writing code that can read it (though that later part can us

Re: [Openstack] OSAPI equivalent of euca-get-console-output ?

Moving forward this should be exposed in something like /servers/{id}/rax/console to avoid conflicts. -jOrGe W. On Oct 21, 2011, at 1:57 PM, Glen Campbell wrote: At Rackspace, we have developed an extension that returns the URL of a console via /servers/{id}/console. The issue for putting thi

Re: [Openstack] Some updates to REST API specs

We had extend discussions about the HTTP error code that we retuned for rate limiting while discussing the compute API. The issue is that we allow users to discover and query their rate limits. So an over-limit response should be in the 400 range because we see it as a client error. None of t

Re: [Openstack] Guidelines for OpenStack APIs

++ Like the idea..yes I think we should aim to include all OpenStack APIs -- whatever that means :-) -jOrGe W. On Oct 11, 2011, at 9:52 AM, Jay Pipes wrote: > On Tue, Oct 11, 2011 at 10:08 AM, Mark McLoughlin wrote: >> On Tue, 2011-10-11 at 16:11 +1100, Mark Nottingham wrote: >>> +1 (sorry for

[Openstack] Repose now on GitHub

Thanks to all who attended our chat Repose today. Just wanted to send a quick message to let you know that the code is available today on GitHub! https://github.com/rackspace/repose -jOrGe W. This email may include confidential information. If you received it in error, please delete it. ___

Re: [Openstack] Guidelines for OpenStack APIs

Starting from a set of goals makes sense to me as well. I had put together a sample set of goals for the PPB proposal a week or so ago and some sample guidelines. You can find them here. Standards for standards sake don't make sense to me either. http://wiki.openstack.org/Governance/Proposed/API

Re: [Openstack] Guidelines for OpenStack APIs

On 9/19/11 1:03 AM, "Mark McLoughlin" wrote: >The spec is actually quite clear on the different between PUT and POST: > > "The fundamental difference between the POST and PUT requests is > reflected in the different meaning of the Request-URI. The URI in a > POST request identifies the res

Re: [Openstack] API Spec

On Aug 24, 2011, at 12:02 PM, Soren Hansen wrote: 2011/8/24 Jorge Williams mailto:jorge.willi...@rackspace.com>>: Let me start by saying that I have no idea why we're having this discussion again. We talked about it at the design summit and we agreed we'd move forward in pretty

Re: [Openstack] API Spec

at I really care where it lives, I just don't remember talking about it. > > 2011/8/23 Jorge Williams : >> I don't have a problem moving the spec out of docs manuals and into another >> project even the nova repo. But, I do have a number of issues with the >&g

Re: [Openstack] API Spec

capabilities can be tested before they make it to the core. -jOrGe W. On Aug 23, 2011, at 1:51 PM, Soren Hansen wrote: > 2011/8/23 Jorge Williams : >> Imagine >> that Rackspace comes up with a feature to perform backups and places it in >> /backups. HP comes up with it

Re: [Openstack] API Spec

I'd love to keep you on as a reviewer Anne, having you in the loop is really helpful -- I don't want to lose that aspect of it. I agree that we need a better governance model. +1 on separate repos for books though that doesn't necessarily have to be 1:1. -jOrGe W. On Aug 23, 2011, at 10:19 AM

Re: [Openstack] API Spec

features that may not get common support across service providers, and because no one will bother using those clients anyway. Christopher MacGown Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (415) 300-0944 ch...@pistoncloud.com<mailto:ch...@pistoncloud.com> On Aug 22, 2011, at 9:18 PM

Re: [Openstack] API Spec

deprecated, how long does backwards > compatibility stay in place? > > Thanks, > Thor W > > On Mon, Aug 22, 2011 at 5:49 PM, Jan Drake wrote: >> +1 >> >> >> >> >> On Aug 22, 2011, at 5:06 PM, Jay Pipes wrote: >> >>> ++ >>

Re: [Openstack] API Spec

On Aug 22, 2011, at 5:06 PM, Jay Pipes mailto:jaypi...@gmail.com>> wrote: > ++ > > On Mon, Aug 22, 2011 at 7:59 PM, Jorge Williams > mailto:jorge.willi...@rackspace.com>> wrote: >> Hi Vish, >> I don't have a problem moving the spec out of docs manuals

Re: [Openstack] API Spec

On Aug 22, 2011, at 8:59 PM, Vishvananda Ishaya wrote: > Inline > > On Aug 22, 2011, at 4:15 PM, Jay Pipes wrote: > >> It may be just me, but having DocBookXML in the source tree is hideous >> to me. Not only does it clutter the source tree with non-RST >> documentation, but as you know, review

Re: [Openstack] API Spec

Comments inline On Aug 22, 2011, at 9:05 PM, Vishvananda Ishaya wrote: > Inline > On Aug 22, 2011, at 4:59 PM, Jorge Williams wrote: > >> Hi Vish, >> >> I don't have a problem moving the spec out of docs manuals and into another >> project even the n

Re: [Openstack] API Spec

#x27;t useful enough to expose through the API, why are we including it in trunk? Christopher MacGown Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (415) 300-0944 ch...@pistoncloud.com<mailto:ch...@pistoncloud.com> On Aug 22, 2011, at 4:59 PM, Jorge Williams wrote: Hi Vish, I don

Re: [Openstack] API Spec

Hi Vish, I don't have a problem moving the spec out of docs manuals and into another project even the nova repo. But, I do have a number of issues with the approach that you're proposing. First, I think that fundamentally there should be a decoupling of the spec and the implementation. If y

Re: [Openstack] Physical host identification

Right so we should really be hashing this with the tenant ID as well. -jOrGe W. On Jul 15, 2011, at 6:16 PM, Chris Behrens wrote: > I think it's sensitive because one could figure out how many hosts a SP has > globally... which a SP might not necessarily want to reveal. > > - Chris > > > On

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

On Jul 8, 2011, at 10:44 PM, Sandy Walsh wrote: > > Wow, really? Is EC2 really that sporadic/chaotic? > > I have to plead ignorance because I don't know where the rubber meets the > road, but that kinda surprises me. I'm not saying that. In fact let me say that I don't think the Windows API

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

implement against an Open API. -jOrGe W. On Jul 8, 2011, at 2:41 PM, Soren Hansen wrote: > 2011/7/8 Jorge Williams : >> I'm with Ewan on this point: One of the nice thing about having a contract >> is that it clearly designates what's a bug and what isn't. If

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

HTTP, SMTP, and IMAP and even ANSI C are all open standards. The specs were developed and continue to be developed in the open -- and both clients and servers (proprietary and open source) are very compliant to them. I'd like to propose that our APIs take the same approach. You are proposin

Re: [Openstack] Refocusing the Lunr Project

Chuck, What does this mean in terms of APIs? Will there be a separate Volume API? Will volumes be embedded in the compute API? -jOrGe W. On Jul 8, 2011, at 10:40 AM, Chuck Thier wrote: Openstack Community, Through the last few months the Lunr team has learned many things. This week, it ha

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

s+sandy.walsh=rackspace@lists.launchpad.net > [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf > of Jorge Williams [jorge.willi...@rackspace.com] > Sent: Friday, July 08, 2011 12:01 PM > To: Soren Hansen > Cc: Ewan Mellor; openstack@lists.launchp

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

I'm with Ewan on this point: One of the nice thing about having a contract is that it clearly designates what's a bug and what isn't. If the spec says the ID is a string and the client assumes it's an integer, then the client is at fault. End of story. It would be a different issue if the c

[Openstack] Compute API 1.1 -- Seeking Community Input

Hello All, New version of OpenStack Compute 1.1 API spec is out. PDF: http://docs.openstack.org/cactus/openstack-compute/developer/openstack-compute-api-1.1/os-compute-devguide-cactus.pdf WebHelp: http://docs.openstack.org/cactus/openstack-compute/developer/openstack-compute-api-1.1/content/in

Re: [Openstack] Feedback on HTTP APIs

>> On Fri, Jun 3, 2011 at 11:34 AM, Thorsten von Eicken >> wrote: Really? The way I understand it, when I retrieve resource X I will get a bookmark link for X. But when I retrieve resource Y that happens to have a reference to X this references will not include the bookmark link fo

Re: [Openstack] OpenStack Identity: Keystone API Proposal

On Jun 21, 2011, at 11:49 PM, Ziad Sawalha wrote: Hi Bryan - A general comment, which colors much of the thinking on Keystone, is that we are looking to have pluggable backends and protocols. We provide a sqlite implementation for reference and for ease of deployment, but it is not the intent

Re: [Openstack] [NetStack] Quantum Service API extension proposal

? How will they share the authentication part > (assuming the core API part has handled the authentication)? > > Best, > Ying > >> -Original Message- >> From: Jorge Williams [mailto:jorge.willi...@rackspace.com] >> Sent: Thursday, May 26, 2011 7:48 PM >&

[Openstack] Extensions Guide

Hey Guys, I've been working on a guide to extensions that will form the basis of a proposal for a standard extensions mechanism to the PPB. You can find the doc here: http://docs.openstack.org/trunk/ I only have the high level overview sections for now, but I wanted to get comments sooner rat

Re: [Openstack] XML and JSON for API's

idation and conformance testing is very useful. This isn't strictly an XML vs JSON thing -- though today there are better tools for doing this sort of thing with XML. > > Just my .02. > > Cheers, > > > On 03/06/2011, at 5:20 AM, Jorge Williams wrote: > >>

Re: [Openstack] Feedback on HTTP APIs

The whole idea behind the "bookmark" links is to give you the functionality that you want -- that is a URL without a version number in it. Looks like the implementation hasn't yet added support for that, but it will. -jOrGe W. On Jun 2, 2011, at 5:04 PM, Thorsten von Eicken wrote: We neither

Re: [Openstack] XML and JSON for API's

It's not just about the service itself validating it, its as Joseph said, making sure that the data structures themselves are documented in detail to the client. To my knowledge there is no accepted schema language in JSON though JSON schema is starting to catch on. At the end of the day it

Re: [Openstack] XML and JSON for API's

I think we would lose some of the benefits of REST if we were to support a single format. My experience is that we have two communities of customers some of which prefer XML and others prefer JSON and we should be able to serve both communities. Amazon handles the same problem by supporting tw

Re: [Openstack] Feedback on HTTP APIs

On Jun 2, 2011, at 12:18 PM, George Reese wrote: > I hate UUIDs with a passion. > > * They are text fields, which means slower database indexes They are not text fields they are large integers and you should store them as such. Some databases offer direct support for them. > * They are comp

[Openstack] Changes-Since

How do you guys feel about the changes-since feature? http://docs.openstack.org/cactus/openstack-compute/developer/openstack-compute-api-1.1/content/ch03s08.html It's a very nice feature to have and we brought it in at the request of some of our larger partners. But as Mark noted in the commen

Re: [Openstack] Feedback on HTTP APIs

Hi Mark, I think that the most convenient place to leave comments is in the web help version: http://docs.openstack.org/cactus/openstack-compute/developer/openstack-compute-api-1.1/content/index.html If you scroll down you'll see there's a place for comments at the end of every page. Looking

Re: [Openstack] Conclusion on Pagination (hopefully!) :)

Jay, +1 on this, however, I would also add linking to the API layer -- as we do in compute 1.1. Links make it supper easy for language bindings to traverse pages -- especially in the case that Thorsten points to, where you want to traverse all items in the collection. In this case, a client

Re: [Openstack] [NetStack] Quantum Service API extension proposal

ntum_service/extensions > > For the extension work with LB v1.1, if there is any related > information, could you send me a pointer? > > Best, > Ying > > >> -Original Message- >> From: openstack-bounces+yinliu2=cisco@lists.launchpad.net >&g

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

+1 On May 23, 2011, at 11:54 AM, Vishvananda Ishaya wrote: > So I think we've identified the real problem... > > :) > > sounds like we really need to do the UUID switchover to optimize here. > > Vish > > On May 23, 2011, at 9:42 AM, Jay Pipes wrote: > >> On Mon, May 23, 2011 at 12:33 PM, Bri

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

On May 23, 2011, at 11:25 AM, Sandy Walsh wrote: From: Jorge Williams > So this is 2.0 API stuff -- right. Well, we need it now ... so we have to find a short term solution. > Why not simply have a request on the server list with the reservation id as a > parameter. > This c

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

I'd like to step back and denote that there won't be support for this in the 1.1 API -- unless this is an extension. So this is 2.0 API stuff -- right. Other comments inline: On May 23, 2011, at 10:53 AM, Sandy Walsh wrote: Cool, I think you all understand the concerns here: 1. We can't tre

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

On May 23, 2011, at 10:15 AM, Ed Leafe wrote: > On May 23, 2011, at 10:35 AM, Jorge Williams wrote: > >> If we make the instance ID a unique ID -- which we probably should. Why >> not also treat it as a reservation id and generate/assign it up front? > > >

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

API. Cool. > I was really > just brainstorming about a future, request-centric 2.0 API that would > allow for more atomic operations on the instance creation level. > Okay, I'll follow up. > Cheers! > jay > > On Mon, May 23, 2011 at 10:35 AM, Jorge Williams >

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

Comments inline: On May 23, 2011, at 8:59 AM, Jay Pipes wrote: > Hi Jorge! Comments inline :) > > On Mon, May 23, 2011 at 9:42 AM, Jorge Williams > wrote: >> Hi Sandy, >> My understanding (Correct me if i'm wrong here guys) is that creating >> multiple ins

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

Hi Sandy, My understanding (Correct me if i'm wrong here guys) is that creating multiple instances with a single call is not in scope for the 1.1 API. Same thing for changing the way in which flavors work. Both features can be brought in as extensions though. I should note that when creating

Re: [Openstack] [NetStack] Quantum Service API extension proposal

d more here . >>> >>> >>> Thanks >>> >>> >>> Ram >>> >>> >>> >>> >>> >>> *From:* openstack-bounces+radurair=cisco@lists.launchpad.net [mailto: >>> openstack-bounces+radur

  1   2   >