<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<blockquote cite="mid:7DCA81CB-AB8A-4316-8557-17BF21516559@internap.com"
type="cite">
<div class="WordSection1"><p class="MsoNormal"><span style="font-size:
11pt; font-family: Calibri;">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…</span></p></div>
</blockquote>
IMHO, it would be great to have a separate WG for what is sure to be a
growing group. These may not seem like a big target for initial upstream
commits, but developers have an avid interest in making their
infrastructure run as smoothly as possible. If nothing else, they should
present a whole pile of valid use cases for OpenStack to learn from. <br>
<blockquote cite="mid:7DCA81CB-AB8A-4316-8557-17BF21516559@internap.com"
type="cite">
<div class="WordSection1">
<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"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">That
would be a good question for both WG at Barcelona (at minimum).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Do
we want to make a decision now ? I’m not sure.<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">"Fox, Kevin M"
<a class="moz-txt-link-rfc2396E" href="mailto:Kevin.Fox@pnnl.gov"><Kevin.Fox@pnnl.gov></a><br>
<b>Date: </b>Wednesday, June 22, 2016 at 3:52 PM<br>
<b>To: </b>Jimmy Mcarthur <a class="moz-txt-link-rfc2396E" href="mailto:jimmy@tipit.net"><jimmy@tipit.net></a>, Michael Krotscheck
<a class="moz-txt-link-rfc2396E" href="mailto:krotscheck@gmail.com"><krotscheck@gmail.com></a><br>
<b>Cc: </b>user-committee <a class="moz-txt-link-rfc2396E" href="mailto:user-committee@lists.openstack.org"><user-committee@lists.openstack.org></a><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>
<div>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:Tahoma;color:black">I've been in
that boat for years.<br>
<br>
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.<br>
<br>
I had hoped this WG would take that on, but doesn't seem to want to deal
with it either.<br>
<br>
The projects are very well silo'ed at the moment preventing cross
project work that really is needed and affects users of this type. :/<br>
<br>
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.<br>
<br>
Thanks,<br>
Kevin<o:p></o:p></span></p>
<div>
<div class="MsoNormal" style="text-align:center" align="center"><span
style="color:black">
<hr align="center" size="2" width="100%">
</span></div>
<div id="divRpF888396">
<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"> Jimmy Mcarthur
[<a class="moz-txt-link-abbreviated" href="mailto:jimmy@tipit.net">jimmy@tipit.net</a>]<br>
<b>Sent:</b> Wednesday, June 22, 2016 11:50 AM<br>
<b>To:</b> Michael Krotscheck<br>
<b>Cc:</b> user-committee<br>
<b>Subject:</b> Re: [User-committee] [app] What is an App?</span><span
style="color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">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>
Michael Krotscheck wrote:<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div>
<div>
<p class="MsoNormal"><span style="color:black">Good question! Let me use
a simple Wordpress Blog as an example.<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">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:<o:p></o:p></span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal"
style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
level1 lfo1">
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.<o:p></o:p></li><li
class="MsoNormal"
style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
level1 lfo1">
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.<o:p></o:p></li><li class="MsoNormal"
style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
level1 lfo1">
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.<o:p></o:p></li><li class="MsoNormal"
style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
level1 lfo1">
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.<o:p></o:p></li></ul>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Michael<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Rubber mallet will take
6-12 weeks for delivery, aka Monty needs a head start.<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">On Wed, Jun 22, 2016 at
11:26 AM Jimmy Mcarthur <<a moz-do-not-send="true"
href="mailto:jimmy@tipit.net" target="_blank">jimmy@tipit.net</a>>
wrote:<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><div>
<p class="MsoNormal"><span style="color:black">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>
Michael Krotscheck wrote:<o:p></o:p></span></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div>
<div>
<p class="MsoNormal"><span style="color:black">Let me try to clarify:<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">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.<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">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.<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">Does that provide the
necessary context?<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">Michael<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="color:black">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:<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><div>
<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.<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<o:p></o:p></span></p>
<div>
<div class="MsoNormal" style="text-align:center" align="center"><span
style="color:black">
<hr align="center" size="2" width="100%">
</span></div>
<div>
<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 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?</span><span
style="color:black"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<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 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><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>
</div></blockquote>
</div>
</div></blockquote>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre><span style="color:black">_______________________________________________<o:p></o:p></span></pre>
<pre><span style="color:black">User-committee mailing list<o:p></o:p></span></pre>
<pre><span style="color:black"><a moz-do-not-send="true" href="mailto:User-committee@lists.openstack.org" target="_blank">User-committee@lists.openstack.org</a><o:p></o:p></span></pre>
<pre><span style="color:black"><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><o:p></o:p></span></pre></blockquote>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
</div></blockquote>
</div></blockquote>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body></html>