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

Monty Taylor mordred at inaugust.com
Thu Apr 21 17:20:06 UTC 2016


On 04/21/2016 11:01 AM, Flavio Percoco wrote:
> 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.

Totally agree.




More information about the OpenStack-dev mailing list