Open Stack

As asked 2 meetings ago (and then totally forgotten until I was reminded
last week), I wrote down my thoughts on the purpose on the App Ecosystem
WG, as well as how I believe an "App" should be defined. I'd like to open
the following for discussion, as an update to the mission statement of the
App Ecosystem WG. We'll also discuss it on the phone on Monday.

=====================
TL/DR:
- "To create an ecosystem where a diverse array of applications built for
OpenStack can thrive."
- "An OpenStack App is a software project that relies on an OpenStack SDK."

Our purpose is to create an ecosystem where a diverse array of applications
built for OpenStack can thrive.

A simple statement, which leaves too much undefined. What exactly is an
OpenStack App? Is it a deployment tool? Is it a web UI? Is it an app
deployed on OpenStack instances? Is it a cron job? Who is the user? Is it a
Heat template? Which cloud are they using? Has that cloud been customized?

As the App Ecosystem Working Group, we believe that the common, defining
element of an "OpenStack App" is not whether it is deployed on OpenStack,
but whether it relies on direct access to the OpenStack API's. For example,
we consider Ansible to be an OpenStack app, as its OpenStack cloud core
modules rely on shade's API implementations.

A more nuanced example is that of Pantheon. Their wordpress/django
provisioning may be considered an OpenStack app, if they use the magnum API
to provision their customers' requested instances. Wordpress, however,
would not be, as it is unaware of its compute environment.

We in the App Ecosystem WG cannot, and should not, predict what our users
want to do with OpenStack; the best we can do is provide the tools and
training they need to meet their own business objectives. Tools means
SDK's. Training means tutorials, classes, and sample projects.

"An OpenStack App is a software project that is built on an OpenStack SDK."

What is an SDK? It is a set of tools, in a specific language, that are easy
to use for an engineer working in that language. More importantly, it
supports applications that are built with OpenStack in mind, but _outside_
of the CLA walled garden. An SDK should make an effort to adhere to the
tooling and conventions common in the community it is trying to serve.

Furthermore, SDK's often define usage patterns. Some might be focused on
building User Interfaces, others may be focused on CLI and automation
tooling, yet more are there for API's and business logic. Usage patterns
vary greatly, and it is worth neither the time nor the effort to
provide exhaustive support for every potential use of every API call ever.

Each SDK knows its community; it is not our job to prescribe that
community's needs, nor to tell them what that SDK should, or should not,
support. If asked, we may certainly help them refine their mission, however
providing any form of engineering support, or a
one-size-fits-all certification program, is well out of scope (And futile
besides).

Training and Tutorials, however, are our responsibility. Since we have very
limited resources, we should set some acceptance criteria for FirstApp and
Training resources. In this, as in all things Open Source, contribution is
the only criteria that matters: Is someone willing to do the work?

=====================
Thoughts? Edits? Add them here:
https://etherpad.openstack.org/p/app-ecosystem-wg-mission
=====================

I've got a few more thoughts on what I feel makes a good SDK which came out
of writing this, but they're not really relevant to the scope of the WG
(They're super relevant to my JS SDK work though). Some of the SDK's we
train for will live in the Big Tent, others outside it, yet ultimately
they're all outside of our control. My criteria break down as follows:

"A Good SDK ..."
- ...meets a software engineer on their own turf.
- ...provides convenience methods for the 80% most common use cases.
- ...provides low-level API access for custom calls.

That's it for me. Let the discussion begin!

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20160622/38b087d2/attachment.html>