<div dir="ltr"><div><div>Great post Ben, I largely agree with what you are saying, a lot of your points<br></div>are valid concerns that I share. Just a couple of comments inline as I try to <br></div>avoid what others have said.<br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 22 January 2016 at 17:24, Ben Nemec <span dir="ltr"><<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So I haven't weighed in on this yet, in part because I was on vacation<br>
when it was first proposed and missed a lot of the initial discussion,<br>
and also because I wanted to take some time to order my thoughts on it.<br>
Also because my initial reaction...was not conducive to calm and<br>
rational discussion. ;-)<br>
<br>
The tldr is that I don't like it. To explain why, I'm going to make a<br>
list (everyone loves lists, right? Top $NUMBER reasons we should stop<br>
expecting other people to write our API for us):<br>
<br>
1) We've been down this road before. Except last time it was with Heat.<br>
I'm being somewhat tongue-in-cheek here, but expecting a general<br>
service to provide us a user-friendly API for our specific use case just<br>
doesn't make sense to me.<br></blockquote><div><br></div><div>I don't really expect the API to be used directly by many users - how many<br></div><div>users directly used the Tuskar API? I suspect they all used it via the CLI<br></div><div>tools or the GUI. I could be completely wrong with the assumption but I think<br></div><div>the primary entry points will be the CLI and GUI we expose. Only advanced <br></div><div>users would need to consider Mistral.<br><br></div><div>Anyone directly interfacing with the API's will need to learn a ton of services,<br></div><div>I don't think Mistral adds much more complexity here.<br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) The TripleO API is not a workflow API. I also largely missed this<br>
discussion, but the TripleO API is a _Deployment_ API. In some cases<br>
there also happens to be a workflow going on behind the scenes, but<br>
honestly that's not something I want our users to have to care about.<br></blockquote><div><br></div><div>Yeah, I agree that one of the downsides of the Mistral approach is that we<br></div><div>blur the lines between these two.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3) It ties us 100% to a given implementation. If Mistral proves to be a<br>
poor choice for some reason, or insufficient for a particular use case,<br>
we have no alternative. If we have an API and decide to change our<br>
implementation, nobody has to know or care. This is kind of the whole<br>
point of having an API - it shields users from all the nasty<br>
implementation details under the surface.<br>
<br>
4) It raises the bar even further for both new deployers and developers.<br>
You already need to have a pretty firm grasp of Puppet and Heat<br>
templates to understand how our stuff works, not to mention a decent<br>
understanding of quite a number of OpenStack services.<br>
<br>
This presents a big chicken and egg problem for people new to OpenStack.<br>
It's great that we're based on OpenStack and that allows people to peek<br>
under the hood and do some tinkering, but it can't be required for<br>
everyone. A lot of our deployers are going to have little to no<br>
OpenStack experience, and TripleO is already a daunting task for those<br>
people (hell, it's daunting for people who _are_ experienced).<br>
<br>
5) What does reimplementing all of our tested, well-understood Python<br>
into a new YAML format gain us? This is maybe the biggest thing I'm<br>
missing from this whole discussion. We lose a bunch of things (ease of<br>
transition from other Python projects, excellent existing testing<br>
framework, etc.), but what are we actually gaining other than the<br>
ability to say that we use N + 1 OpenStack services? Because we're way<br>
past the point where "It's OpenStack deploying OpenStack" is sufficient<br>
reason for people to pay attention to us. We need less "Ooh, neat" and<br>
more "Ooh, that's easy to use and works well." It's still not clear to<br>
me that Mistral helps in any way with the latter.<br>
<br>
6) On the testing note, how do we test these workflows? Do we know what<br>
happens when step X fails? How do we test that they handle it properly<br>
in an automated and repeatable way? In Python these are largely easy<br>
questions to answer: unit tests. How do you unit test YAML? This is a<br>
big reason I'm not even crazy about having Mistral on the back end of a<br>
TripleO API. We'd be going from code that we can test and prove works<br>
in a variety of scenarios, to YAML that is tested and proven to work in<br>
exactly the three scenarios we run in CI. This is basically the same<br>
situation we had with tripleo-incubator, and it was bad there too.<br>
<br>
I dunno. Maybe I'm too late to this party to have any impact on the<br>
discussion, but I very much do not like the direction we're going and I<br>
would be remiss if I didn't at least point out my concerns with it.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Ben<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 01/13/2016 03:41 AM, Tzu-Mainn Chen wrote:<br>
> Hey all,<br>
><br>
> I realize now from the title of the other TripleO/Mistral thread [1] that<br>
> the discussion there may have gotten confused. I think using Mistral for<br>
> TripleO processes that are obviously workflows - stack deployment, node<br>
> registration - makes perfect sense. That thread is exploring practicalities<br>
> for doing that, and I think that's great work.<br>
><br>
> What I inappropriately started to address in that thread was a somewhat<br>
> orthogonal point that Dan asked in his original email, namely:<br>
><br>
> "what it might look like if we were to use Mistral as a replacement for the<br>
> TripleO API entirely"<br>
><br>
> I'd like to create this thread to talk about that; more of a 'should we'<br>
> than 'can we'. And to do that, I want to indulge in a thought exercise<br>
> stemming from an IRC discussion with Dan and others. All, please correct me<br>
> if I've misstated anything.<br>
><br>
> The IRC discussion revolved around one use case: deploying a Heat stack<br>
> directly from a Swift container. With an updated patch, the Heat CLI can<br>
> support this functionality natively. Then we don't need a TripleO API; we<br>
> can use Mistral to access that functionality, and we're done, with no need<br>
> for additional code within TripleO. And, as I understand it, that's the<br>
> true motivation for using Mistral instead of a TripleO API: avoiding custom<br>
> code within TripleO.<br>
><br>
> That's definitely a worthy goal... except from my perspective, the story<br>
> doesn't quite end there. A GUI needs additional functionality, which boils<br>
> down to: understanding the Heat deployment templates in order to provide<br>
> options for a user; and persisting those options within a Heat environment<br>
> file.<br>
><br>
> Right away I think we hit a problem. Where does the code for 'understanding<br>
> options' go? Much of that understanding comes from the capabilities map<br>
> in tripleo-heat-templates [2]; it would make sense to me that responsibility<br>
> for that would fall to a TripleO library.<br>
><br>
> Still, perhaps we can limit the amount of TripleO code. So to give API<br>
> access to 'getDeploymentOptions', we can create a Mistral workflow.<br>
><br>
> Retrieve Heat templates from Swift -> Parse capabilities map<br>
><br>
> Which is fine-ish, except from an architectural perspective<br>
> 'getDeploymentOptions' violates the abstraction layer between storage and<br>
> business logic, a problem that is compounded because 'getDeploymentOptions'<br>
> is not the only functionality that accesses the Heat templates and needs<br>
> exposure through an API. And, as has been discussed on a separate TripleO<br>
> thread, we're not even sure Swift is sufficient for our needs; one possible<br>
> consideration right now is allowing deployment from templates stored in<br>
> multiple places, such as the file system or git.<br>
><br>
> Are we going to have duplicate 'getDeploymentOptions' workflows for each<br>
> storage mechanism? If we consolidate the storage code within a TripleO<br>
> library, do we really need a *workflow* to call a single function? Is a<br>
> thin TripleO API that contains no additional business logic really so bad<br>
> at that point?<br>
><br>
> My gut reaction is to say that proposing Mistral in place of a TripleO API<br>
> is to look at the engineering concerns from the wrong direction. The<br>
> Mistral alternative comes from a desire to limit custom TripleO code at all<br>
> costs. I think that is an extremely dangerous attitude that leads to<br>
> compromises and workarounds that will quickly lead to a shaky code base<br>
> full of design flaws that make it difficult to implement or extend any<br>
> functionality cleanly.<br>
><br>
> I think the correct attitude is to simply look at the problem we're<br>
> trying to solve and find the correct architecture. For these get/set<br>
> methods that the API needs, it's pretty simple: storage -> some logic -><br>
> a REST API. Adding a workflow engine on top of that is unneeded, and I<br>
> believe that means it's an incorrect solution.<br>
><br>
><br>
> Thanks,<br>
> Tzu-Mainn Chen<br>
><br>
><br>
><br>
> [1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-January/083757.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-January/083757.html</a><br>
> [2] <a href="https://github.com/openstack/tripleo-heat-templates/blob/master/capabilities_map.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/master/capabilities_map.yaml</a><br>
><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>
><br>
<br>
<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></div></div></div>