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<thie...@openstack.org> wrote:
Christopher Aedo wrote:
On Mon, Mar 6, 2017 at 3:26 AM, Thierry Carrez<thie...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
