There¹s one more issue with lowest common denominator API. Every time a new version of native client is released, magnum will be responsible for making those sure the common denominator API works with that version of native client. Since the native client will always have more functions/features than the common denominator API, it means the end users will have to use native client for some operations and magnum API for others.
-Raj Raj Patel raj.pa...@rackspace.com <mailto:raj.pa...@rackspace.com> On 4/21/16, 11:03 AM, "Tim Bell" <tim.b...@cern.ch> wrote: > > >On 21/04/16 17:38, "Hongbin Lu" <hongbin...@huawei.com> wrote: > >> >> >>> -----Original Message----- >>> From: Adrian Otto [mailto:adrian.o...@rackspace.com] >>> Sent: April-21-16 10: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 <harlo...@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. >> >>If Magnum want to avoid the risk of picking the wrong COE, that mean the >>risk is populated to all our users. They might pick a COE and explore >>the its complexities. Then they find out another COE is more compelling >>and their integration work is wasted. I wonder if we can do better by >>taking the risk and provide insurance for our users? I am trying to >>understand the rationales that prevents us to improve the integration >>between COEs and OpenStack. Personally, I don't like to end up with a >>situation that "this is the pain from our users, but we cannot do >>anything". > >We¹re running Magnum and have requests from our user communities for >Kubernetes, Docker Swarm and Mesos. The use cases are significantly >different and can justify the selection of different technologies. We¹re >offering Kubernetes and Docker Swarm now and adding Mesos. If I was only >to offer one, they¹d build their own at considerable cost to them and the >IT department. > >Magnum allows me to make them all available under the single umbrella of >quota, capacity planning, identity and resource lifecycle. As experience >is gained, we may make a recommendation for those who do not have a >strong need but I am pleased to be able to offer all of them under the >single framework. > >Since we¹re building on the native APIs for the COEs, the effect from the >operator side to add new engines is really very small (compared to trying >to explain to the user that they¹re wrong in choosing something different >from the IT department). > >BTW, our users also really appreciate using the native APIs. > >Some more details at >http://superuser.openstack.org/articles/openstack-magnum-on-the-cern-produ >ction-cloud and we¹ll give more under the hood details in a further blog. > >Tim > >> >>> >>> 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-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 >>_________________________________________________________________________ >>_ >>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 __________________________________________________________________________ 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
