> 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? 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? 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? d) If we proceed down the Mistral path and run into issues, is there a point when we'd be willing to back away? 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
