The work on the plug-ins can still be done by Magnum core contributors (or anyone). My point is that the work doesn’t have to be code-coupled to Magnum except via the plug-in interface, which, like heat resources, should be relatively straight forward. Creating the plug-in framework in this way allows for leverage of work by non-Magnum contributors and re-use of Chef/Ansible/Heat/PickYourFavoriteHere tool for infra configuration and orchestration.
-Keith On 4/20/16, 6:03 PM, "Hongbin Lu" <hongbin...@huawei.com> wrote: > > >> -----Original Message----- >> From: Keith Bray [mailto:keith.b...@rackspace.com] >> Sent: April-20-16 6:13 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified >> abstraction for all COEs >> >> Magnum doesn¹t have to preclude tight integration for single COEs you >> speak of. The heavy lifting of tight integration of the COE in to >> OpenStack (so that it performs optimally with the infra) can be modular >> (where the work is performed by plug-in models to Magnum, not performed >> by Magnum itself. The tight integration can be done by leveraging >> existing technologies (Heat and/or choose your DevOps tool of choice: >> Chef/Ansible/etc). This allows interested community members to focus on >> tight integration of whatever COE they want, focusing specifically on > >I agree that tight integration can be achieved by a plugin, but I think >the key question is who will do the work. If tight integration needs to >be done, I wonder why it is not part of the Magnum efforts. From my point >of view, pushing the work out doesn't seem to address the original pain, >which is some users don't want to explore the complexities of individual >COEs. > >> the COE integration part, contributing that integration focus to Magnum >> via plug-ins, without having to actually know much about Magnum, but >> instead >> contribute to the COE plug-in using DevOps tools of choice. Pegging >> Magnum to one-and-only one COE means there will be a Magnum2, Magnum3, >> etc. project for every COE of interest, all with different ways of >> kicking off COE management. Magnum could unify that experience for >> users and operators, without picking a winner in the COE space < this >> is just like Nova not picking a winner between VM flavors or OS types. >> It just facilitates instantiation and management of thins. Opinion >> here: The value of Magnum is in being a light-weight/thin API, >> providing modular choice and plug-ability to COE provisioning and >> management, thereby providing operators and users choice of COE >> instantiation and management (via the bay concept), where each COE can >> be as tightly or loosely integrated as desired by different plug-ins >> contributed to perform the COE setup and configurations. So, Magnum >> could have two or more swarm plug-in options contributed to the >> community.. One overlays generic swarm on VMs. >> The other swarm plug-in could instantiate swarm tightly integrated to >> neutron, keystone, etc on to bare metal. Magnum just facilities a >> plug-in model with thin API to offer choice of CEO instantiation and >> management. >> The plug-in does the heavy lifting using whatever methods desired by >> the curator. >> >> That¹s my $0.2. >> >> -Keith >> >> On 4/20/16, 4: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... >> > >> >> >> >> 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