<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 27 January 2016 at 08:10, Tzu-Mainn Chen <span dir="ltr"><<a href="mailto:tzumainn@redhat.com" target="_blank">tzumainn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> Okay, so I initially thought we weren't making much progress on this<br>
> discussion, but after some more thought and reading of the existing PoC,<br>
> we're (maybe?) less far apart than I initially thought.<br>
><br>
> I think there are kind of three different designs being discussed.<br>
><br>
> 1) Rewrite a bunch of stuff into MistrYAML, with the idea that users<br>
> could edit our workflows. I think this is what I've been most<br>
> strenuously objecting to, and for the most part my previous arguments<br>
> pertain to this model.<br>
><br>
> 2) However, I think there's another thing going on/planned with at least<br>
> some of the actions. It sounds like some of our workflows are going to<br>
> essentially be a single action that just passes the REST params into our<br>
> Python code. This sort of API as a Service would be more palatable to<br>
> me, as it doesn't really split our implementation between YAML and<br>
> Python (the YAML is pretty much only defining the REST API in this<br>
> model), but it still gives us a quick and easy REST interface to the<br>
> existing code. It also keeps a certain amount of separation between<br>
> Mistral and the TripleO code in case we decide some day that we need a<br>
> proper API service and need to swap out the Mistral frontend for a<br>
> different one. This should also be the easiest to implement since it<br>
> doesn't involve rewriting anything - we're mostly just moving the<br>
> existing code into Mistral actions and creating some pretty trivial<br>
> Mistral workflows.<br>
><br>
> 3) The thing I _want_ to see, which is a regular Python-based API<br>
> service. Again, you can kind of see my arguments around why I think we<br>
> should do this elsewhere in the thread. It's also worth noting that<br>
> there is already an initial implementation of this proposed to<br>
> tripleo-common, so it's not like we'd be starting from zero here either.<br>
><br>
> I'm still not crazy about 2, but if it lets me stop spending excessive<br>
> amounts of time on this topic it might be worth it. :-)<br>
><br><br></div></div>I'm kinda with Ben here; I'm strongly for 3), but 2) is okay-ish - with a<br>
few caveats. This thread has raised a lot of interesting points that, if<br>
clarified, might help me feel more comfortable about 2), so I'm hoping<br>
that Dan/Steve, you'd be willing to help me understand a few things:<br><br>
a) One argument against the TripleO API is that the Tuskar API tied us<br>
far too strongly with one way of doing things. However, the Mistral<br>
solution would create a set of workflows that essentially have the same<br>
interface as the TripleO API, correct? If so, would we support those<br>
workflows the same as if they were an API, with extensive documentation<br>
and guaranteeing stability from version to version of TripleO?<br></blockquote><div><br></div><div>I believe we would, yes. This needs to be a stable interface, if we really need<br></div><div>to make breaking changes then we could use versions in the workflow names<br></div><div>which Dan suggested at one point.<br></div><div><br><div><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
b) For simple features that we might expose through the Mistral API as<br>
one-step workflows calling a single function (getting parameters for a<br>
deployment, say): when we expose these features through the CLI, would we<br>
also enforce the CLI going through Mistral to access those features rather<br>
than calling that single function?<br></blockquote><div><br></div><div>I think we should, it is just much simpler to have everyone use the same interface<br></div><div>than decide of a case by case basis. However, I could be persuaded otherwise<br></div><div>if others object to this.<br></div><div><br><div><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
c) Is there consideration to the fact that multiple OpenStack projects<br>
have created their own REST APIs to the point that seems like more of<br>
a known technology than using Mistral to front everything? Or are we<br>
going to argue that other projects should also switch to using Mistral?<br></blockquote><div><br></div><div>Projects are so different, that I don't think this can really be compared so<br></div><div>widely. It doesn't really make sense. Projects should be free to choose <br></div><div>which approach suits them best.<br></div></div></div></div></blockquote><div><br></div><div>So what makes TripleO different here? I think this is fundamental to my objection, so<br></div><div>maybe if I understood this point my objections would fall away.<br></div><div><br></div><div>Mainn<br></div><div><br></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
d) If we proceed down the Mistral path and run into issues, is there a<br>
point when we'd be willing to back away?<br></blockquote><div><br></div><div>I don't imagine anyone wants to beat a dead horse. So, yeah, if it doesn't<br></div><div>work out we should reevaluate things. I feel like we have constantly been<br></div><div>doing this for some time (for better or worse).<br></div><div><br></div><div>I am still of the opinion that we can always add an API in-front of Mistral <br></div><div>later if it doesn't work out well. If we start doing this early enough in the<br></div><div>cycle that should give us time to have feedback and see. It might even<br></div><div>be worth somebody creating a POC API that uses the Mistral workflows<br></div><div>to explore the idea.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><span style="color: #888888;" data-mce-style="color: #888888;" color="#888888"><br>
<br>
Mainn<br>
</span></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></div></blockquote></div><br></div></div><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote><div><br></div></div></body></html>