[openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?
tzumainn at redhat.com
Tue Jan 26 15:40:51 UTC 2016
----- Original Message -----
> On Tue, Jan 26, 2016 at 09:23:00AM -0500, Tzu-Mainn Chen wrote:
> > ----- Original Message -----
> > > 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.
> > >
> > Just a quick note about this; developer capacity works both ways. On a
> > practical level, if we were to get involved with Mistral wouldn't we need
> > developers to get deeply involved with the Mistral community? If Mistral
> > were to become the effective REST API interface for the whole deployment
> > API, bugs like https://bugs.launchpad.net/mistral/+bug/1423054 which affect
> > load would have to be fixed, right?
> Well, sure the advantage of not solving only for TripleO is that some
> time can presumably be spent working on helping to improve Mistral instead
> of writing a new API completely from scratch. In general this is a good
> thing, and to be encouraged, right? :)
I don't think this is an entirely fair comparison. Using Mistral as our REST
API feels like a new use of Mistral, and we're not expecting other OpenStack
projects to follow suit, are we? I think there may be unknown consequences to
putting a workflow engine in front of every single REST API request.
> You've mentioned that bug before, have you seen this?
> I'm not sure it's even a bug, it's not confirmed as such and it sounds like
> the configuration issues mentioned in that thread to me.
Fair enough, thanks for pointing that out!
> But, sure, there will be bugs, are you suggesting we'll have less if we
> start from scratch with a TripleO specific API? Be interested to
> understand your reasoning if so :)
I think there's a slightly subtle point being missed. Sure, the Mistral API
exists, but presumably we'd create workflows corresponding to each proposed
TripleO API function. Those workflows would be our true 'API', and I expect
that TripleO would have to provide a guarantee of stability there. I would
expect development of those workflows to have roughly the same amount of
issues as creating a TripleO API.
If we're talking solely about creating a REST API - then yeah, I think that
creating a REST API is well-demonstrated throughout OpenStack, and using
Mistral as the REST API interface is less so.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev