<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 9:09 AM, Jiri Tomasek <span dir="ltr"><<a href="mailto:jtomasek@redhat.com" target="_blank">jtomasek@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">On 01/25/2016 12:42 AM, Clint Byrum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Excerpts from Dan Prince's message of 2016-01-22 16:19:07 -0800:<br>
</blockquote></div></div><span class="">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I actually think rather than shielding users we should be more<br>
transparent about the actual workflows that are driving deployment.<br>
Smaller more focused workflows that we string together to drive the<br>
deployment.<br>
<br>
</blockquote>
I tend to agree, especially when your workflows may need to be<br>
customized.<br>
</blockquote>
<br></span>
Customizing underlining deployment workflows is IMO potentially very dangerous regarding updates etc. and should be avoided as much as possible.</blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace">​+1 to Jiri.<br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I was in the process of replying about the same point :).<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">It should not be the intent that TripleO *users* or *operators* are encouraged or supported to edit the implementation, whether it be yaml workflows or python code. If it is, then we've failed at building a stable interface.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">If we go with a workflow tool that is backed by yaml defined workflows, then those workflows are implementations of an abstraction. In the same way that python code is an implementation of a Restful API if we did a new TripleO API. As a user, no one would have the expectation that editing that python code is encouraged or supported. It ought to be the same with the yaml workflows if we go that route -- they aren't meant to be modified by users/operators.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">We have direct experience with this already...tripleo-heat-templates. We have kind of tried to define a "stable" interface around a pile of yaml files already, and more or less failed. We know that we can't provide reliable updates/upgrades if we don't know how the templates have been modified. There could be many reasons for this: we weren't disciplined enough in code reviews to keep from breaking ourselves, we lack the knowledge to recognize a breaking change in the templates, or just generally that it's really not well known/accepted how to even build a stable interface around yaml files. Whereas, it's quite universally well known and understood how to build stable REST API's.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">So whether the API is a new TripleO Rest API, or the Mistral Rest API, I hope we can agree that the API is the stable part, and the implementation is not meant to be edited by users.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">If we can't agree on that, then we aren't even really discussing the same point IMO. As it's not really a question of which is the better tool, TripleO API / Mistral / Ansible, it's actually a question of "how is TripleO meant to be used".<br></div><div class="gmail_default" style="font-family:monospace,monospace"></div><br clear="all"></div></div><br>-- <br><div class="gmail_signature">-- James Slagle<br>--</div>
</div></div>