Open Stack

There's an alternate vision which is simply, resources that can be launched in an OpenStack environment directly.

Solum, Mistral, Glance, etc fit into that definition. This is kind of how it is arranged today.

Even with the high level app store only vision I proposed, these other types of catalog entries will probably be needed since the higher level app store's apps will probably depend on them...

Say I want to create a Cloud Application that as part of it, launches a rather obscure, hard to build database software as the backend of a set of web servers... Having that part of the app be a Glance Image might be the best way to go. So your Cloud App would depend on maybe a heat template, and a couple of Glance Images (the appliance and a generic Linux one being loaded too).

I know the glance folks want to support storing these things as part of their artefact api, which is good, but there still is the discovery part of it that the app catalog can provide...

So, maybe we really need two different types of things in the catalog.
 * Applications (thing that a user will launch, and optionally answer a few questions)
 * Resources (OpenStack resources. Glance, Heat, Solum, Mistral, etc Artefacts that Applications use, or users can manually use directly if they have the know how.)

Then when the application catalog users that are not developers go to the ui, it would only present the first category of things.

Thanks,
Kevin

________________________________
From: Keith Bray [keith.bray at RACKSPACE.COM]
Sent: Wednesday, May 27, 2015 4:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps

Kevin, I like your vision.  Today we have images, heat templates, Murano packages.  What are your thoughts on how to manage additions?  Should it be restricted to things in the OpenStack namespace under the big tent?  E.g., I'd like to see Solum language packs get added to the app-catalog.  Solum is currently in stack forge, but meets all the criteria I believe to enter OpenStack namespace.  We plan to propose it soon. Folks from various companies did a lot of work the past few summits to clearly distinguish, Heat, Murano, Mistral, and Solum as differentiated enough to co-exist and add value to the ecosystem.

Thanks,
-Keith

From: <Fox>, Kevin M <Kevin.Fox at pnnl.gov<mailto:Kevin.Fox at pnnl.gov>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, May 27, 2015 6:27 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps

I'd say, tools that utilize OpenStack, like the knife openstack plugin, are not something that you would probably go to the catalog to find. And also, the recipes that you would use with knife would not be specific to OpenStack in any way, so you would just be duplicating the config management system's own catalog in the OpenStack catalog, which would be error prone. Duplicating all the chef recipes, and docker containers, puppet stuff, and ..... is a lot of work...

The vision I have for the Catalog (I can be totally wrong here, lets please discuss) is a place where users (non computer scientists) can visit after logging into their Cloud, pick some app of interest, hit launch, and optionally fill out a form. They then have a running piece of software, provided by the greater OpenStack Community, that they can interact with, and their Cloud can bill them for. Think of it as the Apple App Store for OpenStack.  Having a reliable set of deployment engines (Murano, Heat, whatever) involved is critical to the experience I think. Having too many of them though will mean it will be rare to have a cloud that has all of them, restricting the utility of the catalog. Too much choice here may actually be a detriment.

If chef, or what ever other configuration management system became multitenant aware, and integrated into OpenStack and provided by the Cloud providers, then maybe it would fit into the app store vision?

Thanks,
Kevin
________________________________
From: Joe Gordon [joe.gordon0 at gmail.com<mailto:joe.gordon0 at gmail.com>]
Sent: Wednesday, May 27, 2015 3:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps



On Fri, May 22, 2015 at 9:06 PM, Christopher Aedo <caedo at mirantis.com<mailto:caedo at mirantis.com>> wrote:
I want to start off by thanking everyone who joined us at the first
working session in Vancouver, and those folks who have already started
adding content to the app catalog. I was happy to see the enthusiasm
and excitement, and am looking forward to working with all of you to
build this into something that has a major impact on OpenStack
adoption by making it easier for our end users to find and share the
assets that run on our clouds.

Great job. This is very exciting to see, I have been wanting something like this for some time now.


The catalog: http://apps.openstack.org
The repo: https://github.com/stackforge/apps-catalog
The wiki: https://wiki.openstack.org/wiki/App-Catalog

Please join us via IRC at #openstack-app-catalog on freenode.

Our initial core team is Christopher Aedo, Tom Fifield, Kevin Fox,
Serg Melikyan.

I’ve started a doodle poll to vote on the initial IRC meeting
schedule, if you’re interested in helping improve and build up this
catalog please vote for the day/time that works best and get involved!
http://doodle.com/vf3husyn4bdkui8w

At the summit we managed to get one planning session together. We
captured that on etherpad[1], but I’d like to highlight here a few of
the things we talked about working on together in the near term:

-More information around asset dependencies (like clarifying
requirements for Heat templates or Glance images for instance),
potentially just by providing better guidance in what should be in the
description and attributes sections.
-With respect to the assets that are listed in the catalog, there’s a
need to account for tagging, rating/scoring, and a way to have
comments or a forum for each asset so potential users can interact
outside of the gerrit review system.
-Supporting more resource types (Sahara, Trove, Tosca, others)

What about expanding the scope of the application catalog to any application that can run *on* OpenStack, versus the implied scope of applications that can be deployed *by* (heat, murano, etc.) OpenStack and *on* OpenStack services (nova, cinder etc.). This would mean adding room for Ansible roles that provision openstack resources [0]. And more generally it would reinforce the point that there is no 'blessed' method of deploying applications on OpenStack, you can use tools developed specifically for OpenStack or tools developed elsewhere.


[0] https://github.com/ansible/ansible-modules-core/blob/1f99382dfb395c1b993b2812122761371da1bad6/cloud/openstack/os_server.py

-Discuss using glance artifact repository as the backend rather than
flat YAML files
-REST API, enable searching/sorting, this would ease native
integration with other projects
-Federated catalog support (top level catalog including contents from
sub-catalogs)
- I’ll be working with the OpenStack infra team to get the server and
CI set up in their environment (though that work will not impact the
catalog as it stands today).

I am pleased to see moving this to OpenStack Infra is a high priority.

A quick nslookup of http://apps.openstack.org shows it us currently hosted on linode at http://nb-23-239-6-45.fremont.nodebalancer.linode.com/. And last I checked linode isn't OpenStack powered.  apps.openstack.org<http://apps.openstack.org> is a great example of the type of application that should be easy to deploy with OpenStack, since as far as I can tell it just needs a web server and that is it. So wearing my OpenStack developer hat on, why did you go with linode and not any one of the OpenStack based public clouds [1]? If OpenStack is not a good solution for workloads like this, then it would be great to know how what needs work.


[1] https://www.openstack.org/marketplace/public-clouds/


There were a ton of great ideas that came up and it was clear there
was WAY more to discuss than we could accomplish in one short session
at the summit.  I’m looking forward to continuing the conversation
here on the mailing list, on IRC, and in Tokyo as well!

[1] https://etherpad.openstack.org/p/YVR-app-catalog-plans

-Christopher

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150528/e3b46c08/attachment.html>