[openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?
shardy at redhat.com
Tue Jan 26 17:12:48 UTC 2016
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"
Maybe it's time we took a step back, away from the invariably flamey
discussion re implementation details, and focus on what the actual
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?
More information about the OpenStack-dev