> -----Original Message----- > From: Keith Bray [mailto:keith.b...@rackspace.com] > Sent: Thursday, April 21, 2016 5:11 PM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@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....@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.b...@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....@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.o...@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 <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. > >> > >>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 > > __________________________________________________________________________ > 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