OpenStack Community App Catalog Review: Issue #1

What is this Community App Catalog thing? Learn how to quickly deploy apps into your OpenStack cluster using Murano.

Hello, folks! Here at OpenStack:Unlocked we have decided to start a monthly digest of news related to the OpenStack Community App Catalog, a project started to help app developers promote their products, and to help cloud admins with their daily duties by providing an easy way for users to deploy applications on their OpenStack clusters. As TechCrunch put it, the OpenStack Community App Catalog enables “users to share templates for setting up apps and services on the platform. This means OpenStack users could get started with Kubernetes and containers on OpenStack or install the CloudFoundry PaaS platform with just a few clicks.”

In order to make sure you have the best chance of getting the most out of the OpenStack Community App Catalog, we want to keep all the community updated with events, apps, contributors and discussions inspired by this project.

To that

In order to make sure you have the best chance of getting the most out of the OpenStack Community App Catalog, we want to keep all the community updated with events, apps, contributors and discussions inspired by this project.

To that end, we will be bring you monthly reports about events such as meetings of the active contributors of the project — including agenda and decisions — and links to selected articles and presentations with some brief editorial explanations, releases of new hands-on apps available for users, and new personalities contributing to the Community App Catalog.

We thought we’d start with a report on what happened at the OpenStack Summit in Tokyo.

OpenStack Community App Catalog at the OpenStack Summit in Tokyo

  • The team decided that despite the name, the OpenStack Images (Glance) v3 API is not actually about images at all, but about artifacts, or metadata about images. So Flavio Percoco, Glance PTL for Mitaka, highlighted this naming problem. Basically, v3 is not the next step in the evolution of Glance after v2, but rather something developed in parallel. Consequently, the decision was to rename it as Artifacts API v1. That means that when it comes to Glance in Mitaka, there are three APIs: Glance API v1 (old images, to be deprecated), Glance API v2 (current images) and Glare (Glance Artifacts Repository, experimental) v1 (or 0.x — the discussion is still in progress). Note that deployers will need a new entry in the Keystone service catalog for Glare.
  • The team also decided that the python client for Glare will be part of python-glanceclient, but the CLI will be implemented as part of the common OpenStack CLI project.
  • Chris Aedo had some concerns, because from his perspective Glance maybe not the best choice for a back-end for the Community App Catalog. By separating Glare out as a separate process, it becomes easier to use Glare as a backend instead, so on the last day of the summit, Mirantis gave a demo of how it works for Glance people, for the PTL of the Community App Catalog, and for Kevin Fox, the core-reviewer for the Community App Catalog who is responsible for the Community App Catalog Horizon Plugin (see screenshots).
  • And speaking of Horizon, the team also discussed another issue: the potential conflict between Murano and the Horizon Plugin for the Community App Catalog: they have similar names (Murano’s official name is “Application Catalog for OpenStack”), and their UIs are very similar as well. Also, they both allow end users to “deploy an application” (though the actual capabilities of that deployments are different).  That possibly causes some misunderstanding for users. So the decision was to make a common tool, which enables users to:
    1. Browse a remote app catalog, such as apps.openstack.org (or even additional catalogs) and find some assets (apps),
    2. Once users find the thing they are interested in, they have a choice.
    3. a) If they have Glare installed locally, they can import the artifact they need from the remote catalog to their own local catalog.

    4. b) If not, they may not import it, but for some types of assets they may have an option to run them locally without storing. For example for Heat templates one may launch the stack out of the remote template on their local Heat implementation (if they have one). 

      c) If no applicable OpenStack components (such as Glare to store artifacts locally, or some plugins for it to support particular artifact types, or other OpenStack components to work with these artifacts, e.g. Murano) are deployed locally, the tool may display a notification or suggestion that they be installed. So this is also an initiative that will help to cross-promote application-related components such as Glare, Heat, and Murano.  

    1. Also this tool lets the user browse the local app catalog (if Glare is installed) and run, delete, or check apps for new available versions.  
    2. Last but not least is the opportunity to see a list of running apps, stop them or execute lifecycle actions for them (for Murano apps).

If you’re interested in the full summary, feel free to check out the PTL’s notes.

Coming soon

So that’s our first report.  In the next few weeks, you can expect more Murano and App Catalog-related content, including an Artifacts API v1 Deep Dive by Alexander Tivelkov, and a comparative study of using Murano Apps and Glance images for implementing WordPress on OpenStack using the Community App Catalog.

If you want to be involved in some of these decisions, the OpenStack Community App Catalog team meets on Thursdays at 1700 UTC in the Freenode IRC channel #openstack-meeting-3.  You can find the December 3 agenda here.

See you next month!

Subscribe to Our Newsletter

Latest Tweets

Suggested Content

LIVE DEMO
Mirantis Application Platform with Spinnaker
WEBINAR
How to Increase the Probability of a VNF Working with Your Cloud