> -----Original Message----- > From: Ian Cordasco [mailto:sigmaviru...@gmail.com] > Sent: April-20-16 1:56 PM > To: Adrian Otto; 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: Adrian Otto <adrian.o...@rackspace.com> > Reply: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Date: April 19, 2016 at 19:11:07 > 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 > > > 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. > > I'm not nearly as familiar with each COE's API as I'm sure some of you > are, but knowing the present quality of Magnum's documentation, the > fact that it's API is not being documented well, and how thinly > stretched most of Magnum's developers already seem to be, I think that > not doing this now (or in the near term is a better option). First, all > of the COEs magnum supports have excellent documentation around their > API and clients. Magnum does not have that at present and would need to > work on that for this effort to be worthwhile to Magnum's users. Second > of all, what little I do know about each COE's API reinforces (in my > opinion) what Adrian has stated above. Finally, it seems like there are > too many focuses for development at the moment (between trying to > improve gating to allow for multiple supported distributions by default, > eliminating the hard reliance on barbican, creating a versioned and > stable API, and other efforts) for the API design to be done well and > documented well. Frankly, I think the magnum team should be focusing on > 1 thing as their top priority right now and have a secondary priority. > What those priorities are, is up to the community, but I don't think > this should be one of those priorities as someone watching the > community to evaluate it's direction and the potential future of Magnum > inside a product.
I think we are debating the long-term direction of the project (not the short-term priorities of individual tasks). The decision will have an impact on the scope of Magnum (to be a COE deployment tool or a container lifecycle management service). Maybe your suggestion is not to make such decision in short term? If yes, could you elaborate? > > -- > Ian Cordasco > > > _______________________________________________________________________ > ___ > 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