Open Stack

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? :)

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.

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 :)

Cheers,

Steve