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