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

Keith Bray keith.bray at RACKSPACE.COM
Thu Apr 21 21:11:25 UTC 2016

100% agreed on all your points… with the addition that the level of
functionality you are asking for doesn’t need to be baked into an API
service such as Magnum.  I.e., Magnum doesn’t have to be the thing
providing the easy-button app deployment — Magnum isn’t and shouldn’t be a
Docker Hub alternative, a Tutum alternative, etc.  A Horizon UI, App
Catalog UI, or OpenStack CLI on top of Heat, Murano, Solum, Magnum, etc.
etc. can all provide this by pulling together the underlying API
services/technologies to give users the easy app deployment buttons.   I
don’t think Magnum should do everything (or next thing we know we’ll be
trying to make Magnum a PaaS, or make it a CircleCI, or … Ok, I’ve gotten
carried away).  Hopefully my position is understood, and no problem if
folks disagree with me.  I’d just rather compartmentalize domain concerns
and scope Magnum to something focused, achievable, agnostic, and easy for
operators to adopt first. User traction will not be helped by increasing
service/operator complexity.  I’ll have to go look at the latest Trove and
Sahara APIs to see how LCD is incorporated, and would love feedback from
Trove and Sahara operators on the value vs. customer confusion or operator
overhead they get from those LCDs if they are required parts of the


On 4/21/16, 3:31 PM, "Fox, Kevin M" <Kevin.Fox at pnnl.gov> wrote:

>There are a few reasons, but the primary one that affects me is Its from
>the app-catalog use case.
>To gain user support for a product like OpenStack, you need users. The
>easier you make it to use, the more users you can potentially get.
>Traditional Operating Systems learned this a while back. Rather then make
>each OS user have to be a developer and custom deploy every app they want
>to run, they split the effort in such a way that Developers can provide
>software through channels that Users that are not skilled Developers can
>consume and deploy. The "App" culture in the mobile space it the epitome
>of that at the moment. My grandmother fires up the app store on her
>phone, clicks install on something interesting, and starts using it.
>Right now, Thats incredibly difficult in OpenStack. You have to find the
>software your interested in, figure out which components your going to
>consume (nova, magnum, which COE, etc) then use those api's to launch
>some resource. Then after that resource is up, then you have to switch
>tools and then use those tools to further launch things, ansible or
>kubectl or whatever, then further deploy things.
>What I'm looking for, is a unified enough api, that a user can go into
>horizon, go to the app catalog, find an interesting app, click
>install/run, and then get a link to a service they can click on and start
>consuming the app they want in the first place. The number of users that
>could use such an interface, and consume OpenStack resources are several
>orders of magnitude greater then the numbers that can manually deploy
>something ala the procedure in the previous paragraph. More of that is
>good for Users, Developers, and Operators.
>Does that help?
>From: Keith Bray [keith.bray at RACKSPACE.COM]
>Sent: Thursday, April 21, 2016 1:10 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
>abstraction for all COEs
>If you don¹t want a user to have to choose a COE, can¹t we just offer an
>option for the operator to mark a particular COE as the ³Default COE² that
>could be defaulted to if one isn¹t specified in the Bay create call?  If
>the operator didn¹t specify a default one, then the CLI/UI must submit one
>in the bay create call otherwise it would fail.
>Kevin, can you clarify Why you have to write scripts to deploy a container
>to the COE?   It can be made easy for the user to extract all the
>runtime/env vars needed for a user to just do ³docker run Š²  and poof,
>container running on Swarm on a Magnum bay.  Can you help me understand
>the script part of it?   I don¹t believe container users want an
>abstraction between them and their COE CLIŠ but, what I believe isn¹t
>important.  What I do think is important is that we not require OpenStack
>operators to run that abstraction layer to be running a ³magnum compliant²
>service.  It should either be an ³optional² API add-on or a separate API
>or separate project.  If some folks want an abstraction layer, then great,
>feel free to build it and even propose it under the OpenStack ecosystem..
>But, that abstraction would be a ³proxy API" over the COEs, and doesn¹t
>need to be part of Magnum¹s offering, as it would be targeted at the COE
>interactions and not the bay interactions (which is where Magnum scope is
>best focused).  I don¹t think Magnum should play in both these distinct
>domains (Bay interaction vs. COE interaction).  The former (bay
>interaction) is an infrastructure cloud thing (fits well with OpenStack),
>the latter (COE interaction) is an obfuscation of emerging technologies,
>which gets in to the Trap that Adrian mentioned.  The abstraction layer
>API will forever and always be drastically behind in trying to keep up
>with the COE innovation.
>In summary, an abstraction over the COEs would be best served as a
>different effort.  Magnum would be best focused on bay interactions and
>should not try to pick a COE winner or require an operator to run a
>lowest-common-demonitor API abstraction.
>Thanks for listening to my soap-box.
>On 4/21/16, 2:36 PM, "Fox, Kevin M" <Kevin.Fox at pnnl.gov> wrote:
>>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.
>>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>
>>> Thierry Carrez wrote:
>>>> Adrian Otto wrote:
>>>>> This pursuit is a trap. Magnum should focus on making native
>>>>> 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.
>>>> 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
>>>> take advantage of the cool features in Kubernetes API or the
>>>> 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
>>>> 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)
>>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>OpenStack Development Mailing List (not for usage questions)
>>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list