Open Stack

I agree with that, and thats why providing some bare minimum abstraction will help the users not have to choose a COE themselves. If we can't decide, why can they? If all they want to do is launch a container, they should be able to script up "magnum launch-container foo/bar:latest" and get one. That script can then be relied upon.

Today, they have to write scripts to deploy to the specific COE they have chosen. If they chose Docker, and something better comes out, they have to go rewrite a bunch of stuff to target the new, better thing. This puts a lot of work on others.

Do I think we can provide an abstraction that prevents them from ever having to rewrite scripts? No. There are a lot of features in the COE world in flight right now and we dont want to solidify an api around them yet. We shouldn't even try that. But can we cover a few common things now? Yeah.

Thanks,
Kevin
________________________________________
From: Adrian Otto [adrian.otto at rackspace.com]
Sent: Thursday, April 21, 2016 7:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

> On Apr 20, 2016, at 2:49 PM, Joshua Harlow <harlowja at fastmail.com> 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…

The key issue preventing the selection of only one COE is that this area is moving very quickly. If we would have decided what to pick at the time the Magnum idea was created, we would have selected Docker. If you look at it today, you might pick something else. A few months down the road, there may be yet another choice that is more compelling. The fact that a cloud operator can integrate services with OpenStack, and have the freedom to offer support for a selection of COE’s is a form of insurance against the risk of picking the wrong one. Our compute service offers a choice of hypervisors, our block storage service offers a choice of storage hardware drivers, our networking service allows a choice of network drivers. Magnum is following the same pattern of choice that has made OpenStack compelling for a very diverse community. That design consideration was intentional.

Over time, we can focus the majority of our effort on deep integration with COEs that users select the most. I’m convinced it’s still too early to bet the farm on just one choice.

Adrian

>> I'm with Adrian on that one. I've attended a lot of container-oriented
>> conferences over the past year and my main takeaway is that this new
>> crowd of potential users is not interested (at all) in an
>> OpenStack-specific lowest common denominator API for COEs. They want to
>> take advantage of the cool features in Kubernetes API or the versatility
>> of Mesos. They want to avoid caring about the infrastructure provider
>> bit (and not deploy Mesos or Kubernetes themselves).
>>
>> Let's focus on the infrastructure provider bit -- that is what we do and
>> what the ecosystem wants us to provide.
>>
>
> __________________________________________________________________________
> 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

__________________________________________________________________________
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