Open Stack

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).

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.