Open Stack

----- 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>