<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 1:09 PM, Dan Prince <span dir="ltr"><<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
As for tripleo-heat-templates... sure it hasn't been an entirely smooth<br>
ride. I think a lot of the pain has to do with a lack of CI coverage on<br>
proper upgrade paths upstream. I think this has less to do with the<br>
architecture (certainly not the fact that it uses YAML) and more to do<br>
with the fact that we may have cut corners, jammed a bunch of features<br>
in really fast, and don't have CI to cover proper upgrades jobs.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace">​I think it has a lot less to do with that then it may appear on the surface. Even if we had 100% functional test coverage of upgrade paths, that does nothing to solve for scenarios where the templates have been so heavily customized that stack updates can not be guaranteed to work, or worse, destroy the cloud.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">The most we could do in those scenarios is better detection around what stack changes are going to be done by an update before anything is actually applied. And if something is going to be destructive or is not expected, we refuse to proceed. That would definitely help us as developers to know if our own changes are breaking upgrades.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">But, that doesn't really help the user get their cloud upgraded if they've customized templates themselves, other than they know that they must undo whatever custom changes they made, and if they made those for valid reasons and can't undo, then they are stuck.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">They've taken what may appear as a "feature" of the system -- customizing templates to add support for new things -- and turned it into an anti-feature, now they can't upgrade without writing upgrade support for whatever they added themself. Perhaps having to undo new features we as TripleO developers added for users in the first place.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">I don't think that's a supportable path for users of TripleO, nor sustainable as a community, so editing templates should be advertised as unsupported.<br></div><div class="gmail_default" style="font-family:monospace,monospace">​<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The fact that projects like Heat, Mistral, and Ansible use YAML is to<br>
our advantage as developers. I think it allows us to work faster by<br>
avoiding rather large amounts of code to represent the same sorts of<br>
things. Please, lets not argue that by writing things in Python we<br>
deter end users from editing things we don't want them too. Instead let<br>
the choice be ours... not as Python developers... but as TripleO<br>
deployment developers who choose the write tools for the right jobs.<span><br></span></blockquote><div><br><br><div class="gmail_default" style="font-family:monospace,monospace">Agreed, we can't deter anyone from editing python anymore than we could yaml. <br><br>But it's not about dictating what people do. It's about what we support as a project for users and operators. This is something we can define very clearly so that users aren't surprised. At least they would have some way of knowing if they are using the system as intended.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">I don't think we should support/encourage editing the yaml workflows by end users if ​we choose a yaml based workflow tool, any more than we should support editing python code by users if we wrote our own REST API.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">It's not clear to me in this discussion when the argument about yaml files being easier to edit so Mistral/Ansible is a better choice...if we're talking about developers editing yaml files, or users editing yaml files.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">If it's the former (developers), I agree it's a benefit for us.<br><br>If it's the latter (users), then personally I don't see that as a valid argument at all since I view it as something we should never do.<br></div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
><br>
> So whether the API is a new TripleO Rest API, or the Mistral Rest<br>
> API, I hope we can agree that the API is the stable part, and the<br>
> implementation is not meant to be edited by users.<br>
<br>
</span>We do totally agree on the stable API part. :)<br></blockquote><div><br><div><br><div class="gmail_default" style="font-family:monospace,monospace">​To be clear, are you saying we should have a stable API, and then support users in editing the implementation of that API (yaml workflows)?​<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">For example, we have a stable API such as:<br><br>POST /workbooks/deploy-cloud/executions<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">that might do totally different things across deployed TripleO clouds of the same released version, depending on how the user has customized the deploy-cloud workbook?<br><br></div></div></div></div>-- <br><div>-- James Slagle<br>--</div>
</div></div>