[User-committee] [app] What is an App?
Tom Fifield
tom at openstack.org
Thu Jun 23 05:50:01 UTC 2016
Hi,
Silly question here :)
Is this conversation re-discovering the concepts of cloud apps as
generally being one of:
* Cloud Hosted
* Cloud Optimized
* Cloud Native
?
IIRC there was a presentation about that in Austin or something ...
Regards,
Tom
On 23/06/16 04:09, Bruno Morel wrote:
> 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
>
>
>
> _______________________________________________
> User-committee mailing list
> User-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
More information about the User-committee
mailing list