[User-committee] [app] What is an App?
Jimmy Mcarthur
jimmy at tipit.net
Wed Jun 22 21:48:08 UTC 2016
> 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…
>
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.
>
> 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/808a6aea/attachment-0001.html>
More information about the User-committee
mailing list