[openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Flavio Percoco flavio at redhat.com
Thu Apr 21 16:01:52 UTC 2016

On 21/04/16 12:26 +0200, Thierry Carrez wrote:
>Joshua Harlow wrote:
>>Thierry Carrez wrote:
>>>Adrian Otto wrote:
>>>>This pursuit is a trap. Magnum should focus on making native container
>>>>APIs available. We should not wrap APIs with leaky abstractions. The
>>>>lowest common denominator of all COEs is an remarkably low value API
>>>>that adds considerable complexity to Magnum that will not
>>>>strategically advance OpenStack. If we instead focus our effort on
>>>>making the COEs work better on OpenStack, that would be a winning
>>>>strategy. Support and compliment our various COE ecosystems.
>>So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making
>>COEs work better on OpenStack' but I do dislike the part about COEs
>>(plural) because it is once again the old non-opinionated problem that
>>we (as a community) suffer from.
>>Just my 2 cents, but I'd almost rather we pick one COE and integrate
>>that deeply/tightly with openstack, and yes if this causes some part of
>>the openstack community to be annoyed, meh, to bad. Sadly I have a
>>feeling we are hurting ourselves by continuing to try to be everything
>>and not picking anything (it's a general thing we, as a group, seem to
>>be good at, lol). I mean I get the reason to just support all the
>>things, but it feels like we as a community could just pick something,
>>work together on figuring out how to pick one, using all these bright
>>leaders we have to help make that possible (and yes this might piss some
>>people off, to bad). Then work toward making that something great and
>>move on...
>I see where you come from, but I think this is a bit different from, 
>say, our choice to support multiple DLMs through Tooz instead of just 
>picking ZooKeeper.
>I like to say that OpenStack solves the infrastructure provider 
>problem: what should I install over my datacenter to serve the needs 
>of all my end users. Some want VMs, some want bare metal, some want a 
>Docker host, some want a Kubernetes cluster, some want a Mesos 
>cluster. If we explicitly choose to, say, not support Mesos to only 
>support Kubernetes users, we are no longer a universal solution for 
>that infrastructure provider. He may deploy OpenStack but then will 
>have to tell his end users that they can do everything but Mesos, 
>and/or deploy a Mesos cluster manually on the side if his users end up 
>deciding they want one.
>So while I agree we should get more opinionated on the 
>implementation/deployer-side options (weeding out less supported 
>options/drivers and driving more interoperability), I think we need to 
>support as many infrastructure use cases as we can.
>Happy to talk about that with you next week :)

+1 to the above! Magnum's goal (as also mentioned by Kevin in another email) is
similar to what Trove and Sahara do. I do not believe it should be opinionated.
It solves a different set of issues and it sits in the provisioning plane next
to other services akin.


Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160421/f09a9c04/attachment.pgp>

More information about the OpenStack-dev mailing list