Open Stack

Isn't 2 a description of every OpenStack user? Perhaps I'm misunderstanding
this, but everything deployed onto OpenStack fits that description.

That isn't to say it's not a priority, but that it is so broad that it
completely encompasses the scope of several other working groups, for
example: the product management, cross-project and enterprise WGs.

If the existing set of WGs isn't cutting it, then I don't think a new
massively broad WG is the answer.

​--​
​Roland

On 23 June 2016 at 06:09, Bruno Morel <bmorel at internap.com> 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> 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> 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]
> *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
>
>
>
>
>
> _______________________________________________
> 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/20160623/da5b9692/attachment-0001.html>