Open Stack

> -----Original Message-----
> From: Keith Bray [mailto:keith.bray at RACKSPACE.COM]
> Sent: Thursday, April 21, 2016 5:11 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
> 
> 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
> services.

[amrith] Keith, I'm happy to chat with you about how Trove does all that. I work on Trove, not an operator.

> 
> Thanks,
> -Keith
> 
> 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?
> >
> >Thanks,
> >Kevin
> >
> >
> >________________________________________
> >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.
> >-Keith
> >
> >
> >
> >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.
> >>
> >>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
> >>
> >>______________________________________________________________________
> >>___
> >>_
> >>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
> >
> >_______________________________________________________________________
> >___ 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