Hey all, I realize now from the title of the other TripleO/Mistral thread [1] that the discussion there may have gotten confused. I think using Mistral for TripleO processes that are obviously workflows - stack deployment, node registration - makes perfect sense. That thread is exploring practicalities for doing that, and I think that's great work.
What I inappropriately started to address in that thread was a somewhat orthogonal point that Dan asked in his original email, namely: "what it might look like if we were to use Mistral as a replacement for the TripleO API entirely" I'd like to create this thread to talk about that; more of a 'should we' than 'can we'. And to do that, I want to indulge in a thought exercise stemming from an IRC discussion with Dan and others. All, please correct me if I've misstated anything. The IRC discussion revolved around one use case: deploying a Heat stack directly from a Swift container. With an updated patch, the Heat CLI can support this functionality natively. Then we don't need a TripleO API; we can use Mistral to access that functionality, and we're done, with no need for additional code within TripleO. And, as I understand it, that's the true motivation for using Mistral instead of a TripleO API: avoiding custom code within TripleO. That's definitely a worthy goal... except from my perspective, the story doesn't quite end there. A GUI needs additional functionality, which boils down to: understanding the Heat deployment templates in order to provide options for a user; and persisting those options within a Heat environment file. Right away I think we hit a problem. Where does the code for 'understanding options' go? Much of that understanding comes from the capabilities map in tripleo-heat-templates [2]; it would make sense to me that responsibility for that would fall to a TripleO library. Still, perhaps we can limit the amount of TripleO code. So to give API access to 'getDeploymentOptions', we can create a Mistral workflow. Retrieve Heat templates from Swift -> Parse capabilities map Which is fine-ish, except from an architectural perspective 'getDeploymentOptions' violates the abstraction layer between storage and business logic, a problem that is compounded because 'getDeploymentOptions' is not the only functionality that accesses the Heat templates and needs exposure through an API. And, as has been discussed on a separate TripleO thread, we're not even sure Swift is sufficient for our needs; one possible consideration right now is allowing deployment from templates stored in multiple places, such as the file system or git. Are we going to have duplicate 'getDeploymentOptions' workflows for each storage mechanism? If we consolidate the storage code within a TripleO library, do we really need a *workflow* to call a single function? Is a thin TripleO API that contains no additional business logic really so bad at that point? My gut reaction is to say that proposing Mistral in place of a TripleO API is to look at the engineering concerns from the wrong direction. The Mistral alternative comes from a desire to limit custom TripleO code at all costs. I think that is an extremely dangerous attitude that leads to compromises and workarounds that will quickly lead to a shaky code base full of design flaws that make it difficult to implement or extend any functionality cleanly. I think the correct attitude is to simply look at the problem we're trying to solve and find the correct architecture. For these get/set methods that the API needs, it's pretty simple: storage -> some logic -> a REST API. Adding a workflow engine on top of that is unneeded, and I believe that means it's an incorrect solution. Thanks, Tzu-Mainn Chen [1] http://lists.openstack.org/pipermail/openstack-dev/2016-January/083757.html [2] https://github.com/openstack/tripleo-heat-templates/blob/master/capabilities_map.yaml __________________________________________________________________________ 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