Open Stack

> On 27 January 2016 at 08:10, Tzu-Mainn Chen < tzumainn at redhat.com > wrote:

> > > Okay, so I initially thought we weren't making much progress on this
> 
> > > discussion, but after some more thought and reading of the existing PoC,
> 
> > > we're (maybe?) less far apart than I initially thought.
> 
> > >
> 
> > > I think there are kind of three different designs being discussed.
> 
> > >
> 
> > > 1) Rewrite a bunch of stuff into MistrYAML, with the idea that users
> 
> > > could edit our workflows. I think this is what I've been most
> 
> > > strenuously objecting to, and for the most part my previous arguments
> 
> > > pertain to this model.
> 
> > >
> 
> > > 2) However, I think there's another thing going on/planned with at least
> 
> > > some of the actions. It sounds like some of our workflows are going to
> 
> > > essentially be a single action that just passes the REST params into our
> 
> > > Python code. This sort of API as a Service would be more palatable to
> 
> > > me, as it doesn't really split our implementation between YAML and
> 
> > > Python (the YAML is pretty much only defining the REST API in this
> 
> > > model), but it still gives us a quick and easy REST interface to the
> 
> > > existing code. It also keeps a certain amount of separation between
> 
> > > Mistral and the TripleO code in case we decide some day that we need a
> 
> > > proper API service and need to swap out the Mistral frontend for a
> 
> > > different one. This should also be the easiest to implement since it
> 
> > > doesn't involve rewriting anything - we're mostly just moving the
> 
> > > existing code into Mistral actions and creating some pretty trivial
> 
> > > Mistral workflows.
> 
> > >
> 
> > > 3) The thing I _want_ to see, which is a regular Python-based API
> 
> > > service. Again, you can kind of see my arguments around why I think we
> 
> > > should do this elsewhere in the thread. It's also worth noting that
> 
> > > there is already an initial implementation of this proposed to
> 
> > > tripleo-common, so it's not like we'd be starting from zero here either.
> 
> > >
> 
> > > I'm still not crazy about 2, but if it lets me stop spending excessive
> 
> > > amounts of time on this topic it might be worth it. :-)
> 
> > >
> 

> > I'm kinda with Ben here; I'm strongly for 3), but 2) is okay-ish - with a
> 
> > few caveats. This thread has raised a lot of interesting points that, if
> 
> > clarified, might help me feel more comfortable about 2), so I'm hoping
> 
> > that Dan/Steve, you'd be willing to help me understand a few things:
> 

> > a) One argument against the TripleO API is that the Tuskar API tied us
> 
> > far too strongly with one way of doing things. However, the Mistral
> 
> > solution would create a set of workflows that essentially have the same
> 
> > interface as the TripleO API, correct? If so, would we support those
> 
> > workflows the same as if they were an API, with extensive documentation
> 
> > and guaranteeing stability from version to version of TripleO?
> 

> I believe we would, yes. This needs to be a stable interface, if we really
> need
> to make breaking changes then we could use versions in the workflow names
> which Dan suggested at one point.

> > b) For simple features that we might expose through the Mistral API as
> 
> > one-step workflows calling a single function (getting parameters for a
> 
> > deployment, say): when we expose these features through the CLI, would we
> 
> > also enforce the CLI going through Mistral to access those features rather
> 
> > than calling that single function?
> 

> I think we should, it is just much simpler to have everyone use the same
> interface
> than decide of a case by case basis. However, I could be persuaded otherwise
> if others object to this.

> > c) Is there consideration to the fact that multiple OpenStack projects
> 
> > have created their own REST APIs to the point that seems like more of
> 
> > a known technology than using Mistral to front everything? Or are we
> 
> > going to argue that other projects should also switch to using Mistral?
> 

> Projects are so different, that I don't think this can really be compared so
> widely. It doesn't really make sense. Projects should be free to choose
> which approach suits them best.

So what makes TripleO different here? I think this is fundamental to my objection, so 
maybe if I understood this point my objections would fall away. 

Mainn 

> > d) If we proceed down the Mistral path and run into issues, is there a
> 
> > point when we'd be willing to back away?
> 

> I don't imagine anyone wants to beat a dead horse. So, yeah, if it doesn't
> work out we should reevaluate things. I feel like we have constantly been
> doing this for some time (for better or worse).

> I am still of the opinion that we can always add an API in-front of Mistral
> later if it doesn't work out well. If we start doing this early enough in the
> cycle that should give us time to have feedback and see. It might even
> be worth somebody creating a POC API that uses the Mistral workflows
> to explore the idea.

> > Mainn
> 

> > __________________________________________________________________________
> 
> > 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
> 

> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160128/658f0fdc/attachment.html>