On Tue, Jan 26, 2016 at 10:01:56AM -0600, Ben Nemec wrote: > On 01/26/2016 03:46 AM, Steven Hardy wrote: > > On Mon, Jan 25, 2016 at 05:45:30PM -0600, Ben Nemec wrote: > >> On 01/25/2016 03:56 PM, Steven Hardy wrote: > >>> On Fri, Jan 22, 2016 at 11:24:20AM -0600, Ben Nemec wrote: > >>>> So I haven't weighed in on this yet, in part because I was on vacation > >>>> when it was first proposed and missed a lot of the initial discussion, > >>>> and also because I wanted to take some time to order my thoughts on it. > >>>> Also because my initial reaction...was not conducive to calm and > >>>> rational discussion. ;-) > >>>> > >>>> The tldr is that I don't like it. To explain why, I'm going to make a > >>>> list (everyone loves lists, right? Top $NUMBER reasons we should stop > >>>> expecting other people to write our API for us): > >>>> > >>>> 1) We've been down this road before. Except last time it was with Heat. > >>>> I'm being somewhat tongue-in-cheek here, but expecting a general > >>>> service to provide us a user-friendly API for our specific use case just > >>>> doesn't make sense to me. > >>> > >>> Actually, we've been down this road before with Tuskar, and discovered > >>> that > >>> designing and maintaining a bespoke API for TripleO is really hard. > >> > >> My takeaway from Tuskar was that designing an API that none of the > >> developers on the project use is doomed to fail. Tuskar also suffered > >> from a lack of some features in Heat that the new API is explicitly > >> depending on in an attempt to avoid many of the problems Tuskar had. > >> > >> Problem #1 is still developer apathy IMHO though. > > > > I think the main issue is developer capacity - we're a small community and > > I for one am worried about the effort involved with building and > > maintaining a bespoke API - thus this whole discussion is essentially about > > finding a quicker and easier way to meet the needs of those needing an API. > > > > In terms of apathy, I think as a developer I don't need an abstraction > > between me, my templates and heat. Some advanced operators will feel > > likewise, others won't. What I would find useful sometimes is a general > > purpose workflow engine, which is where I think the more pluggable mistral > > based solution may have advantages in terms of developer and advanced > > operator uptake. > > The API is for end users, not developers. tripleo-incubator was easily > hackable for developers and power users. It was unusable for everyone else.
I'm sorry but you are contradicting your previous "doomed to fail" assertion here. Maybe it's time we took a step back, away from the invariably flamey discussion re implementation details, and focus on what the actual requirement is. 1. We need an opinionated and strongly versioned abstraction for UIs and non-advanced CLI use-cases. 2. We also need that abstraction to add some value to advanced users and developers, or they won't use it. How can we do both? Steve __________________________________________________________________________ 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
