<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mv="http://macVmlSchemaUri" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style id=owaParaStyle>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Courier New";
panose-1:2 7 3 9 2 2 5 2 4 4;}
@font-face
{font-family:"Cambria Math";
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Courier;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:Calibri;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">+1 <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Totally concur<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Bruno<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black">Jimmy Mcarthur <jimmy@tipit.net><br>
<b>Date: </b>Wednesday, June 22, 2016 at 1:04 PM<br>
<b>To: </b>"Fox, Kevin M" <Kevin.Fox@pnnl.gov><br>
<b>Cc: </b>user-committee <user-committee@lists.openstack.org><br>
<b>Subject: </b>Re: [User-committee] [app] What is an App?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">I second this. We build web applications for the Foundation that run on OpenStack instances. By and large, we have no need to touch the OpenStack API. However, we rely on OpenStack for our infrastructure. This is, IMO, a very big potential
market and something that we should be sure to include. If not in this WG, then some other.
<br>
<br>
Cheers!<br>
Jimmy <br>
<br>
<br>
Fox, Kevin M wrote:<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Tahoma;color:black">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.<o:p></o:p></span></p>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Tahoma;color:black"><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<o:p></o:p></span></p>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="color:black">
<hr size="2" width="100%" align="center">
</span></div>
<div id="divRpF950176">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:10.0pt;font-family:Tahoma;color:black">From:</span></b><span style="font-size:10.0pt;font-family:Tahoma;color:black"> Michael Krotscheck [<a href="mailto:krotscheck@gmail.com">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?</span><span style="color:black"><o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:black">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."<o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black"><br>
Our purpose is to create an ecosystem where a diverse array of applications built for OpenStack can thrive.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">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. For example, we consider Ansible to be an OpenStack
app, as its OpenStack cloud core modules rely on shade's API implementations. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">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. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><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).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">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?<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black">=====================<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:black">Thoughts? Edits? Add them here: <a href="https://etherpad.openstack.org/p/app-ecosystem-wg-mission" target="_blank">https://etherpad.openstack.org/p/app-ecosystem-wg-mission</a><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">=====================<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">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:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">"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<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>User-committee mailing list<o:p></o:p></pre>
<pre><a href="mailto:User-committee@lists.openstack.org">User-committee@lists.openstack.org</a><o:p></o:p></pre>
<pre><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee">http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>