<div dir="ltr">Personally I tend to agree with Christopher's POV. IMO the OpenStack community and TC could and should make a progress in perception how to make OpenStack more 'consumable' and useful for a broader audience. And IMO AppCatalog falls into this direction of making OpenStack more consumable and useful. Rather than retiring AppCatalog let's discuss how to improve it, try to figure out what's missing if anything etc.<div>Also please note that Murano is solving much deeper (wider?) problem than Docker app deployment. Murano is more similar to what the Helm is to Kubernetes [1]. Murano offers advanced application and infrastructure integration capabilities.</div><div><br></div><div>[1] <a href="https://github.com/kubernetes/helm">https://github.com/kubernetes/helm</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 8, 2017 at 5:09 AM, Christopher Aedo <span dir="ltr"><<a href="mailto:doc@aedo.net" target="_blank">doc@aedo.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Mar 6, 2017 at 3:26 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>
> Hello everyone,<br>
><br>
> The App Catalog was created early 2015 as a marketplace of pre-packaged<br>
> applications that you can deploy using Murano. Initially a demo by<br>
> Mirantis, it was converted into an open upstream project team, and<br>
> deployed as a "beta" as <a href="http://apps.openstack.org" rel="noreferrer" target="_blank">apps.openstack.org</a>.<br>
><br>
> Since then it grew additional categories (Glance images, Heat & Tosca<br>
> templates), but otherwise did not pick up a lot of steam. The website<br>
> (still labeled "beta") features 45 glance images, 6 Tosca templates, 13<br>
> heat templates and 94 murano packages (~30% of which are just thin<br>
> wrappers around Docker containers). Traffic stats show around 100 visits<br>
> per week, 75% of which only read the index page.<br>
><br>
> In parallel, Docker developed a pretty successful containerized<br>
> application marketplace (the Docker Hub), with hundreds of thousands of<br>
> regularly-updated apps. Keeping the App Catalog around (including its<br>
> thinly-wrapped Docker container Murano packages) make us look like we<br>
> are unsuccessfully trying to compete with that ecosystem, while<br>
> OpenStack is in fact completely complementary.<br>
<br>
</span>Without something like Murano "thinly wrapping" docker apps, how would<br>
you propose current users of OpenStack clouds deploy docker apps?  Or<br>
any other app for that matter?  It seems a little unfair to talk about<br>
murano apps this way when no reasonable alternative exists for easily<br>
deploying docker apps.  When I look back at the recent history of how<br>
we've handled containers (nova-docker, magnum, kubernetes, etc) it<br>
does not seem like we're making it easy for the folks who want to<br>
deploy a container on their cloud...<br>
<br>
Please understand I am not pleading to keep the Community App Catalog<br>
alive in perpetuity.  This just sounds like an unfair point of<br>
comparison.  One of the biggest challenges we've faced with the app<br>
catalog since day one is that there is no such thing as a simple<br>
definition of an "OpenStack Application".  OpenStack is an IaaS before<br>
anything else, and to my knowledge there is no universally accepted<br>
application deployment mechanism for OpenStack clouds.  Heat doesn't<br>
solve that problem as its very operator focused, and while being very<br>
popular and used heavily, it's not used as a way to share generic<br>
templates suitable for deploying apps across different clouds.  Murano<br>
is not widely adopted (last time I checked it's not available on any<br>
public clouds, though I hear it is actually used on a several<br>
university clouds, and it's also used on a few private clouds I'm<br>
aware of.)<br>
<br>
As a place to find things that run on OpenStack clouds, the app<br>
catalog did a reasonable job.  If anything, the experiment showed that<br>
there is no community looking for a place to share OpenStack-specific<br>
applications.  There are definitely communities for PaaS layers (cloud<br>
foundry, mesosphere, docker, kubernetes), but I don't see any<br>
community for openstack-native applications that can be deployed on<br>
any cloud, nor a commonly accepted way to deploy them.<br>
<span class=""><br>
> In the past we have retired projects that were dead upstream. The App<br>
> Catalog is not in this case: it has an active maintenance team, which<br>
> has been successfully maintaining the framework and accepting<br>
> applications. If we end up retiring the App Catalog, it would clearly<br>
> not be a reflection on that team performance, which has been stellar<br>
> despite limited resources. It would be because the beta was arguably not<br>
> successful in building an active marketplace of applications, and<br>
> because its continuous existence is not a great fit from a strategy<br>
> perspective. Such removal would be a first for our community, but I<br>
> think it's now time to consider it.<br>
><br>
> Before we discuss or decide anything at the TC level, I'd like to<br>
> collect everyone thoughts (and questions) on this. Please feel free to<br>
> reply to this thread (or reach out to me privately if you prefer). Thanks !<br>
<br>
</span>As the former PTL I am obviously a little bit biased.  Even though my<br>
focus has shifted and I've stepped away from the app catalog, I had<br>
been spending a lot of time trying to figure out how to make<br>
applications an easy to run thing on OpenStack.  I've also been trying<br>
to find a community of people who are looking for that, and it doesn't<br>
seem like they've materialized; possibly because that community<br>
doesn't exist?  Or else we just haven't been able to figure out where<br>
they're hiding ;)<br>
<br>
The one consideration that is pretty important here is what this would<br>
mean to the Murano community.  Those folks have been contributed time<br>
and resources to the app catalog project.  They've also standardized<br>
on the app catalog as the distribution mechanism, intending to make<br>
the app catalog UI a native component for Murano. We do need to make<br>
sure that if the app catalog is retired, it doesn't hamper or impact<br>
people who have already deployed Murano and are counting on finding<br>
the apps in the app catalog.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Christopher<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> --<br>
> Thierry Carrez (ttx)<br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Adam Heczko</div><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Security Engineer @ Mirantis Inc.</div></div></div>
</div>