Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.
Over the Havana cycle, we pumped up out automation by an order of magnitude. What bits of tooling do we have? Do they work? What do we need? What should we fix?
Following from the session at the previous summit[1][2], let's take stock. Assessing how we did in our restructure efforts over Havana, and plan what structural work is needed over the next cycle or two.
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.
Diane Fleming is working on a blueprint for the continuous improvement of our API docs to help out end-users.
The API docs consist of 1) The API Reference pages, 2) The docs generated from the project-api repos, such as http://docs.openstack.org/api/openstack-compute/2/content/.
I am setting up this session to find out how you use (and would like to use) the project-api repos.
