Icehouse Design Summit

Co-presented by Everett Toews and Tom Fifield

The purpose of this session is to outline a vision, and attempt to define the practical steps that we should take over the next year to achieve it.

The Portal
Can you imagine if we had developer.openstack.org?

A single place where application developers coding in any language could come to learn about openstack and find the resources they need to write scalable cloud applications for OpenStack.

The site would be a portal containing links to other areas:
* All of the SDKs
* CLI docs for scripting e.g. in bash
* API documentation (acknowledging that the majority of developers will use SDKs, not the API directly)
* Where to get help

Existing Python Libraries
Answer the question: are python-*client to be treated as libraries? As in: the Python SDK for OpenStack.
If so, an important parallel of this work would be to asess the current python binding resources and improve them to be an exemplar for other SDKs to follow.

What defines an SDK?
From the wiki (https://wiki.openstack.org/wiki/SDKs):
* A set of language bindings that provide a language-level API for accessing OpenStack in a manner consistent with language standards.
* A Getting Started document that shows how to use the API to access OpenStack powered clouds.
* Detailed API reference documentation.
* Tested sample code that you can use as a "starter kit" for your own OpenStack applications.
* SDKs treat OpenStack as a blackbox and only interact with the REST/HTTP API.
* License must be compatible with Apache License v2.

If an SDK does not meet these criteria, it's not considered an SDK for OpenStack.

Additional criteria could be discussed, such as:
* Does the SDK have an active community?
* Is it promptly updated for new API releases?

Join us to discuss these topics as we refine our vision.


(Session proposed by Everett Toews)