Open Stack

Weirdly as it seem, I think that we are making progress…:)

1/ there is app in the sense of ‘using OpenStack API through SDKs or directly’, which is currently the main focus of the App Eco work group

2/ there is app in the sense of ‘leveraging an Openstack manage infrastructure’, which is where you feel your current pain

3/ and app in the sens of the app-catalog, prepackaged software component ready to be consumed by an OpenStack infrastructure

1 and 3 have respectively WG taking care of those objectives right now (AppEco + AppCatalog), I’d say the question would now be : shall we make one of those group objectives ‘wider’ by including it or shall we retry the ‘cross project’ WG, which hasn’t work…

That would be a good question for both WG at Barcelona (at minimum).
Do we want to make a decision now ? I’m not sure.

Bruno

From: "Fox, Kevin M" <Kevin.Fox at pnnl.gov>
Date: Wednesday, June 22, 2016 at 3:52 PM
To: Jimmy Mcarthur <jimmy at tipit.net>, Michael Krotscheck <krotscheck at gmail.com>
Cc: user-committee <user-committee at lists.openstack.org>
Subject: Re: [User-committee] [app] What is an App?

I've been in that boat for years.

Nova Instance users, dns/ssl cert retrieval, etc. There isn't a great place for work to happen that is focused directly on making the end user experience of the type of App I've been talking about better except the Cross Project WG and that hasn't worked out very well.

I had hoped this WG would take that on, but doesn't seem to want to deal with it either.

The projects are very well silo'ed at the moment preventing cross project work that really is needed and affects users of this type. :/

Each project expects you to contribute a lot to get enough review capital to be listened to, but if your goal is to fix issues that cross projects, its extremely difficult to get enough capital on each project to affect real positive change.

Thanks,
Kevin
________________________________
From: Jimmy Mcarthur [jimmy at tipit.net]
Sent: Wednesday, June 22, 2016 11:50 AM
To: Michael Krotscheck
Cc: user-committee
Subject: Re: [User-committee] [app] What is an App?
So end users of OpenStack, unless they're using the OpenStack API, wouldn't have a place in the App WG. I completely see the distinction on that and appreciate the clarification. As you said, the you have to create a definition for how your "apps" are using OpenStack.

That said, I think this overlooks a huge percentage of users that rely on OpenStack for infrastructure for their apps/web apps and find shortcomings.

An example: you can't currently assign block storage to more than one VM at a time. This is something that I think is just sitting around as a patch to be approve in Neutron, but it's causing major problems for us as web application developers that are deploying on top of OpenStack. Basically, as a result of this and the lack of replication in Trove, we can't cluster.

It's remarkably difficult to get integrated in IRC channels without knowing the lingo. Is there some suggestion from the user committee about where users like us could turn?

Thanks,
Jimmy

Michael Krotscheck wrote:

Good question! Let me use a simple Wordpress Blog as an example.

By itself, WordPress is compute agnostic; It doesn't care if it runs on metal, in a container, or in a VM. It only cares that it has a MySQL database available, as well as a web server and a PHP runtime. We can't, and shouldn't, help you with that, because this problem has already been solved. So let's look at some examples where we can help:

  *   If you'd like to authenticate to your Wordpress Blog using keystone (suspension of disbelief please), we'll provide you with a PHP SDK recommendation, some examples on how to use it, training (if feasible), and recommend that you check the wordpress plugin guide on how to properly integrate the two.
  *   If you'd like to automatically deploy your Wordpress Blog using Ansible, we'd step back. Installing wordpress is the same whether you're installing on a VM or on metal.
  *   If you'd like to provision the VM for your blog, we'd refer you (since you're already using it) to the Ansible Core Cloud modules, which contain tons of examples already on how to launch an instance, setup a network, and attach a volume.
  *   If you discover that the Ansible Core Cloud modules don't support Trove, and you'd like to add that, we'd provide you with documentation for shade, our FirstApp examples, a link to the Ansible Core Contributor documents, a large squeaky rubber mallet, and Monty's personal home address.
Michael
Rubber mallet will take 6-12 weeks for delivery, aka Monty needs a head start.

On Wed, Jun 22, 2016 at 11:26 AM Jimmy Mcarthur <jimmy at tipit.net<mailto:jimmy at tipit.net>> wrote:
How would classify apps (and where would you point users) that only use OpenStack as infrastructure and don't touch the API's?

Jimmy

Michael Krotscheck wrote:
Let me try to clarify:

I'm proposing that the App Ecosystem WG does not try to define the meaning of "App" at all. The term is too generic, anyone can overload it to mean what they want. Case and point: You (the App Catalog) already have a definition.

We need to sidestep this argument altogether, and focus instead on what an "app" uses. We will train and support you on how to talk to the OpenStack API's. In many cases, we'll be able to refer you to existing tools and/or SDK's (such as Ansible and/or python-openstacksdk) that have already solved 80% of your problem. For anything else, we'll happily refer you to the correct community.

Does that provide the necessary context?

Michael

On Wed, Jun 22, 2016 at 9:34 AM Fox, Kevin M <Kevin.Fox at pnnl.gov<mailto:Kevin.Fox at pnnl.gov>> wrote:
I've worked for the OpenStack Applications Catalog project for a while, and we've been using a definition of OpenStack Application closer to "Is it an app deployed on OpenStack instances". For a long time now.

There is software, and there are Apps. "Apps" got redefined in most peoples minds when mobile world hit.

Software is something that is hard to install. The installer asks a lot of questions, it needs to be tuned, etc.

An App, is something my grandmother or young child can deploy and use with a click or two. Thats something OpenStack needs more of.

If you go ask random person on the street what an App was, I'd be willing to bet you would get a definition that is similar the mobile one. "I go to the store/catalog/market, search, click install, and then go to "run" and start working/playing".

So I disagree with the definition you laid out as a general term. It is unintuitive in that form. I'd suggest any tagging sorts of endeavours use a different or more specific term like OpenStack API Application or something.

As for what the App Ecosystem WG wants to focus on, I think its great to focus on getting software talking to OpenStack via apis.  No issue there. I just want to make sure that we don't cause further confusion with multiple projects using the same term drastically differently. Its something users have suffered a lot with already.

Thanks,
Kevin
________________________________
From: Michael Krotscheck [krotscheck at gmail.com<mailto:krotscheck at gmail.com>]
Sent: Wednesday, June 22, 2016 9:16 AM
To: user-committee
Subject: [User-committee] [app] What is an App?
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

_______________________________________________

User-committee mailing list

User-committee at lists.openstack.org<mailto:User-committee at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee


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