On 27 January 2016 at 08:10, Tzu-Mainn Chen <tzuma...@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. > 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
