Thats cool. Hopefully something great will come of it. :) Thanks for sharing the link. :)
Kevin ________________________________________ From: Joshua Harlow [harlo...@fastmail.com] Sent: Thursday, April 21, 2016 2:06 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs I thought this was also what the goal of https://cncf.io/ was starting to be? Maybe to early to tell if that standardization will be an real outcome vs just an imagined outcome :-P -Josh Fox, Kevin M wrote: > The COE's have a pressure not to standardize their api's between competing > COE's. If you can lock a user into your api, then they cant go to your > competitor. > > The standard api really needs to come from those invested in not being locked > in. OpenStack's been largely about that since the beginning. It may not > belong in Magnum, but I do believe it belongs in OpenStack. > > Thanks, > Kevin > ________________________________________ > From: Steve Gordon [sgor...@redhat.com] > Sent: Thursday, April 21, 2016 6:39 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified > abstraction for all COEs > > ----- Original Message ----- >> From: "Hongbin Lu"<hongbin...@huawei.com> >> To: "OpenStack Development Mailing List (not for usage >> questions)"<openstack-dev@lists.openstack.org> >>> -----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. > > Why does the integration belong in Magnum though? To me it belongs in the > COEs themselves (e.g. their in-tree network/storage plugins) such that > someone can leverage them regardless of their choices regarding COE > deployment tooling (and yes that means Magnum should be able to leverage them > too)? I guess the issue is that in the above conversation we are overloading > the term "integration" which can be taken to mean different things... > > -Steve > >> 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. > > > __________________________________________________________________________ > 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
