Open Stack

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
> 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/41b76ce1/attachment-0001.html>