----- 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? > > http://lists.openstack.org/pipermail/openstack-dev/2015-December/082717.html > > 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. Mainn > Cheers, > > Steve > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
