<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">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. <br>
<br>
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. <br>
<br>
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.<br>
<br>
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? <br>
<br>
Thanks,<br>
Jimmy<br>
<br>
<span>Michael Krotscheck wrote:</span><br>
<blockquote
cite="mid:CABM65avJKEmrOyfa2B7YehQ9uj9gaiBAarST1L1VP3jgUta3hw@mail.gmail.com"
type="cite">
<div dir="ltr"><div style="font-size:small">Good question! Let me use a
simple Wordpress Blog as an example.</div><div style="font-size:small"><br></div><div
style="font-size:small">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:</div><div style="font-size:small"><ul><li><span
style="line-height:1.5">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.</span><br></li><li><span
style="line-height:1.5">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.</span></li><li><span
style="line-height:1.5">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.</span></li><li><span
style="line-height:1.5">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.</span></li></ul></div><div
style="font-size:small">Michael</div><div style="font-size:small">Rubber
mallet will take 6-12 weeks for delivery, aka Monty needs a head start.</div></div>
<br>
<div class="gmail_quote"><div dir="ltr">On Wed, Jun 22, 2016 at 11:26
AM Jimmy Mcarthur <<a moz-do-not-send="true"
href="mailto:jimmy@tipit.net">jimmy@tipit.net</a>> wrote:<br></div><blockquote
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">How would
classify apps
(and where would you point users) that only use OpenStack as
infrastructure and don't touch the API's?<br>
<br>
Jimmy<br>
<br>
<span>Michael Krotscheck wrote:</span><br>
</div><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite"><div
dir="ltr"><div>Let me try to clarify:</div><div><br></div><div>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.</div><div><br></div><div>We need to sidestep this argument
altogether, and focus instead on what an "app" uses. W<span
style="line-height:1.5">e 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. </span><span
style="line-height:1.5">For anything else, we'll happily refer you to
the correct community.</span></div><div><br></div><div>Does that provide
the necessary context?</div><div><br></div><div>Michael</div><br><div
class="gmail_quote"><div dir="ltr">On Wed, Jun 22, 2016 at 9:34 AM Fox,
Kevin M <<a moz-do-not-send="true" href="mailto:Kevin.Fox@pnnl.gov"
target="_blank">Kevin.Fox@pnnl.gov</a>>
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div
style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">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.<br>
<br>
There is software, and there are Apps. "Apps" got redefined in most
peoples minds when mobile world hit.<br>
<br>
Software is something that is hard to install. The installer asks a lot
of questions, it needs to be tuned, etc.<br>
<br>
An App, is something my grandmother or young child can deploy and use
with a click or two. Thats something OpenStack needs more of.<br>
<br>
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".<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
Kevin<br>
<div style="font-family:Times New Roman;color:#000000;font-size:16px">
<hr>
<div style="direction:ltr"><font color="#000000" face="Tahoma" size="2"><b>From:</b>
Michael Krotscheck [<a moz-do-not-send="true"
href="mailto:krotscheck@gmail.com" target="_blank">krotscheck@gmail.com</a>]<br>
<b>Sent:</b> Wednesday, June 22, 2016 9:16 AM<br>
<b>To:</b> user-committee<br>
<b>Subject:</b> [User-committee] [app] What is an App?<br>
</font><br>
</div></div></div></div><div><div
style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div
style="font-family:Times New Roman;color:#000000;font-size:16px">
<div>
<div dir="ltr">
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.<br>
<br>
=====================<br>
TL/DR:<br>
- "To create an ecosystem where a diverse array of applications built
for OpenStack can thrive."<br>
- "An OpenStack App is a software project that relies on an OpenStack
SDK."<br>
<div><br>
Our purpose is to create an ecosystem where a diverse array of
applications built for OpenStack can thrive.<br>
<br>
</div>
<div>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? <br>
<br>
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. <span style="line-height:1.5">For example, we consider
Ansible to be an</span><span style="line-height:1.5"> OpenStack app, as
its OpenStack cloud core modules rely on shade's API implementations. </span></div>
<div><span style="line-height:1.5"><br>
</span></div>
<div><span style="line-height:1.5">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 </span><span style="line-height:1.5">is unaware of its
compute environment. </span></div>
<div><br>
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. <br>
<br>
"An OpenStack App is a software project that is built on an OpenStack
SDK." <br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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).</div>
<div><br>
</div>
<div>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?<br>
<br>
<div>=====================</div>
Thoughts? Edits? Add them here: <a moz-do-not-send="true"
href="https://etherpad.openstack.org/p/app-ecosystem-wg-mission"
target="_blank">https://etherpad.openstack.org/p/app-ecosystem-wg-mission</a></div>
<div>=====================</div>
<div><br>
</div>
<div>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:<br>
<br>
</div>
<div>"A Good SDK ..." <br>
- ...meets a software engineer on their own turf. <br>
- ...provides convenience methods for the 80% most common use cases. <br>
- ...provides low-level API access for custom calls. <br>
<br>
That's it for me. Let the discussion begin!<br>
<br>
Michael</div>
</div>
</div>
</div></div></div></blockquote></div></div></blockquote></div><div
bgcolor="#FFFFFF" text="#000000"><blockquote type="cite"><pre>_______________________________________________
User-committee mailing list
<a moz-do-not-send="true" href="mailto:User-committee@lists.openstack.org" target="_blank">User-committee@lists.openstack.org</a>
<a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee</a>
</pre></blockquote>
<br>
</div></blockquote></div>
</blockquote>
<br>
</body></html>