Open Stack

> -----Original Message-----
> From: Ian Cordasco [mailto:sigmavirus24 at 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.otto at rackspace.com>
> Reply: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Date: April 19, 2016 at 19:11:07
> 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
> 
> > 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-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev