Open Stack

-----Original Message-----
From: Christopher Aedo <doc at aedo.net>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Date: March 7, 2017 at 22:11:22
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [tc][appcat][murano][app-catalog] The
future of the App Catalog

> On Mon, Mar 6, 2017 at 3:26 AM, Thierry Carrez wrote:
> > Hello everyone,
> >
> > The App Catalog was created early 2015 as a marketplace of pre-packaged
> > applications that you can deploy using Murano. Initially a demo by
> > Mirantis, it was converted into an open upstream project team, and
> > deployed as a "beta" as apps.openstack.org.
> >
> > Since then it grew additional categories (Glance images, Heat & Tosca
> > templates), but otherwise did not pick up a lot of steam. The website
> > (still labeled "beta") features 45 glance images, 6 Tosca templates, 13
> > heat templates and 94 murano packages (~30% of which are just thin
> > wrappers around Docker containers). Traffic stats show around 100 visits
> > per week, 75% of which only read the index page.
> >
> > In parallel, Docker developed a pretty successful containerized
> > application marketplace (the Docker Hub), with hundreds of thousands of
> > regularly-updated apps. Keeping the App Catalog around (including its
> > thinly-wrapped Docker container Murano packages) make us look like we
> > are unsuccessfully trying to compete with that ecosystem, while
> > OpenStack is in fact completely complementary.
>
> Without something like Murano "thinly wrapping" docker apps, how would
> you propose current users of OpenStack clouds deploy docker apps? Or
> any other app for that matter? It seems a little unfair to talk about
> murano apps this way when no reasonable alternative exists for easily
> deploying docker apps. When I look back at the recent history of how
> we've handled containers (nova-docker, magnum, kubernetes, etc) it
> does not seem like we're making it easy for the folks who want to
> deploy a container on their cloud...
>
> Please understand I am not pleading to keep the Community App Catalog
> alive in perpetuity. This just sounds like an unfair point of
> comparison. One of the biggest challenges we've faced with the app
> catalog since day one is that there is no such thing as a simple
> definition of an "OpenStack Application". OpenStack is an IaaS before
> anything else, and to my knowledge there is no universally accepted
> application deployment mechanism for OpenStack clouds. Heat doesn't
> solve that problem as its very operator focused, and while being very
> popular and used heavily, it's not used as a way to share generic
> templates suitable for deploying apps across different clouds. Murano
> is not widely adopted (last time I checked it's not available on any
> public clouds, though I hear it is actually used on a several
> university clouds, and it's also used on a few private clouds I'm
> aware of.)
>
> As a place to find things that run on OpenStack clouds, the app
> catalog did a reasonable job. If anything, the experiment showed that
> there is no community looking for a place to share OpenStack-specific
> applications. There are definitely communities for PaaS layers (cloud
> foundry, mesosphere, docker, kubernetes), but I don't see any
> community for openstack-native applications that can be deployed on
> any cloud, nor a commonly accepted way to deploy them.
>
> > In the past we have retired projects that were dead upstream. The App
> > Catalog is not in this case: it has an active maintenance team, which
> > has been successfully maintaining the framework and accepting
> > applications. If we end up retiring the App Catalog, it would clearly
> > not be a reflection on that team performance, which has been stellar
> > despite limited resources. It would be because the beta was arguably not
> > successful in building an active marketplace of applications, and
> > because its continuous existence is not a great fit from a strategy
> > perspective. Such removal would be a first for our community, but I
> > think it's now time to consider it.
> >
> > Before we discuss or decide anything at the TC level, I'd like to
> > collect everyone thoughts (and questions) on this. Please feel free to
> > reply to this thread (or reach out to me privately if you prefer). Thanks !
>
> As the former PTL I am obviously a little bit biased. Even though my
> focus has shifted and I've stepped away from the app catalog, I had
> been spending a lot of time trying to figure out how to make
> applications an easy to run thing on OpenStack. I've also been trying
> to find a community of people who are looking for that, and it doesn't
> seem like they've materialized; possibly because that community
> doesn't exist? Or else we just haven't been able to figure out where
> they're hiding ;)
>
> The one consideration that is pretty important here is what this would
> mean to the Murano community. Those folks have been contributed time
> and resources to the app catalog project. They've also standardized
> on the app catalog as the distribution mechanism, intending to make
> the app catalog UI a native component for Murano. We do need to make
> sure that if the app catalog is retired, it doesn't hamper or impact
> people who have already deployed Murano and are counting on finding
> the apps in the app catalog.

All of this is true. But Murano still doesn't have a stable way to
store artifacts. In fact, it seems like Murano relies on a lot of
unstable OpenStack infrastructure. While lots of people have
contributed time, energy, sweat, and tears to the project there are
still plenty of things that make Murano less than desirable. Perhaps
that's why the project has found so few adopters. I'm sure there are
plenty of people who want to use an OpenStack cloud to deploy
applications. In fact, I know there are companies that try to provide
that kind of support via Heat templates. All that said, I don't think
allowing for competition with Murano is a bad thing.

--
Ian Cordasco