[openstack-dev] [tc][appcat][murano][app-catalog] The future of the App Catalog

Joshua Harlow harlowja at fastmail.com
Fri Mar 10 18:15:17 UTC 2017

Clint Byrum wrote:
> Excerpts from Thierry Carrez's message of 2017-03-10 16:48:02 +0100:
>> Christopher Aedo wrote:
>>> On Thu, Mar 9, 2017 at 4:08 AM, Thierry Carrez<thierry at openstack.org>  wrote:
>>>> Christopher Aedo wrote:
>>>>> On Mon, Mar 6, 2017 at 3:26 AM, Thierry Carrez<thierry at openstack.org>  wrote:
>>>>>> [...]
>>>>>> 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...
>>>> I'd say there are two approaches: you can use the container-native
>>>> approach ("docker run" after provisioning some container-enabled host
>>>> using Nova or K8s cluster using Magnum), or you can use the
>>>> OpenStack-native approach (zun create nginx) and have it
>>>> auto-provisioned for you. Those projects have a narrower scope, and
>>>> fully co-opt the container ecosystem without making us appear as trying
>>>> to build our own competitive application packaging/delivery/marketplace
>>>> mechanism.
>>>> I just think that adding the Murano abstraction in the middle of it and
>>>> using an AppCatalog-provided Murano-powered generic Docker container
>>>> wrapper is introducing unnecessary options and complexity -- options
>>>> that are strategically hurting us when we talk to those adjacent
>>>> communities...
>>> OK thank you for making it clearer, now I understand where you're
>>> coming from.  I do agree with this sentiment.  I don't have any
>>> experience with zun but it sounds like it's the least-cost way to
>>> deploy a docker at for the environments where it's installed.
>>> I think overall the app catalog was an interesting experiment, but I
>>> don't think it makes sense to continue as-is.  Unless someone comes up
>>> with a compelling new direction, I don't see much point in keeping it
>>> running.  Especially since it sounds like Mirantis is on board (and
>>> the connection to a murano ecosystem was the only thing I saw that
>>> might be interesting).
>> Right -- it's also worth noting that I'm only talking about the App
>> Catalog here, not about Murano. Zun might be a bit too young for us to
>> place all our eggs in the same basket, and some others pointed to how
>> Murano is still viable alternative package for things that are more
>> complex than a set of containers. What I'm questioning at the moment is
>> the continued existence of a marketplace that did not catch fire as much
>> as we hoped -- an app marketplace with not enough apps just hurts more
>> than it helps imho.
>> In particular, I'm fine if (for example) the Docker-wrapper murano
>> package ends up being shipped as a standard/example package /in/ Murano,
>> and continues to exist there as a "reasonable alternative for easily
>> deploying docker apps" :)
> While we were debating how to do everything inside our walls, Google
> and Microsoft became viable public cloud vendors along side the other
> players. We now live in a true multi-cloud world (not just a theoretical
> one).

Yes, plllllease if we could stop thinking as a community that everyone 
and everything is inside the openstack wall; and that every company that 
deploys or uses openstack only uses things inside that wall (because 
they don't); companies don't IMHO care anymore (if they ever did) if a 
project is in the openstack wall or not, they care about it being useful 
and working and maintainable/sustainable.

> And what I see when I look outside our walls is not people trying to make
> the initial steps identical or easy. For that there's PaaS. Instead, for
> those that want the full control of their computers that IaaS brings,
> there's a focus on making it simple, and growing a process that works
> the same for the parts that are the same, and differently for the parts
> that are different.
> I see things like Terraform embracing the differences in clouds, not
> hiding behind lowest common denominators. So if you want a Kubernetes on
> GCE and one on OpenStack, you'd write two different Terraform plans
> that give you the common set of servers you expect, get you config
> management and kubernetes setup and hooked into the infrastructure
> however it needs to be, and then get out of your way.
> So, while I think it's cool to make sure we are supporting our users
> when all they want is us, it might make more sense to do that outside
> our walls, where we can meet the rest of the cloud world too.
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list