Open Stack

On Tue, 2014-02-25 at 09:26 -0500, Sean Dague wrote:
> What I want out of Nova API at the end of the day:
> 
> 1. a way to discover what the API is
> 
> because this massively simplifies writing clients, SDKs, tests, and
> documentation. All those pipelines are terribly manual, and have errors
> in them because of it. Like has been said before you actually need to
> read the Nova source code to figure out how to use parts of the API.

++

The key here, IMO, is to have JSON-Schema documents returned in the same
manner as Glance's v2 API and Heroku's API does, with separate schema
documents returned for each resource exposed in the API.

> 2. stop being optional
> 
> If we ever want interoperability between Nova implementations we need to
> stop allowing the API to be optional. That means getting rid of
> extensions. Content is either part of the Nova API, or it isn't in the
> tree. Without this we'll never get an ecosystem around the API because
> anything more complicated than basic server lifecycle is not guarunteed
> to exist in an OpenStack implementation.
> 
> Extensions thus far have largely just been used as a cheat to get around
> API compatibility changes based on the theory that users could list
> extensions to figure out what the API would look like. It's a bad
> theory, and not even nova command line does this. So users will get
> errors on nova cli with clouds because features aren't enabled, and the
> user has no idea why their commands don't work. Because it's right there
> in the nova help.

No surprise... 100% agreement from me on this.

> 3. a solid validation surface
> 
> We really need to be far more defensive on our API validation surface.
> Right now bad data makes it far too far down the code stack. That's just
> a recipe for security issues.

++. WSME makes this kind of thing much more solid. What is/was the
status of WSME/Pecan integration in Nova?

Best,
-jay