<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 10:46 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 2016-01-25 at 15:08 -0500, James Slagle wrote:<br>
><br>
><br>
</span><div><div class="h5">> On Mon, Jan 25, 2016 at 1:09 PM, Dan Prince <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>><br>
> wrote:<br>
> >  <br>
> > As for tripleo-heat-templates... sure it hasn't been an entirely<br>
> > smooth<br>
> > ride. I think a lot of the pain has to do with a lack of CI<br>
> > 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<br>
> > do<br>
> > with the fact that we may have cut corners, jammed a bunch of<br>
> > features<br>
> > in really fast, and don't have CI to cover proper upgrades jobs.<br>
> I think it has a lot less to do with that then it may appear on the<br>
> surface. Even if we had 100% functional test coverage of upgrade<br>
> paths, that does nothing to solve for scenarios where the templates<br>
> have been so heavily customized that stack updates can not be<br>
> guaranteed to work, or worse, destroy the cloud.<br>
><br>
> The most we could do in those scenarios is better detection around<br>
> what stack changes are going to be done by an update before anything<br>
> is actually applied. And if something is going to be destructive or<br>
> is not expected, we refuse to proceed. That would definitely help us<br>
> as developers to know if our own changes are breaking upgrades.<br>
><br>
> But, that doesn't really help the user get their cloud upgraded if<br>
> they've customized templates themselves, other than they know that<br>
> they must undo whatever custom changes they made, and if they made<br>
> those for valid reasons and can't undo, then they are stuck.<br>
><br>
> They've taken what may appear as a "feature" of the system --<br>
> customizing templates to add support for new things -- and turned it<br>
> into an anti-feature, now they can't upgrade without writing upgrade<br>
> support for whatever they added themself. Perhaps having to undo new<br>
> features we as TripleO developers added for users in the first place.<br>
><br>
> I don't think that's a supportable path for users of TripleO, nor<br>
> sustainable as a community, so editing templates should be advertised<br>
> as unsupported.<br>
><br>
>  <br>
> >  <br>
> > The fact that projects like Heat, Mistral, and Ansible use YAML is<br>
> > 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<br>
> > 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<br>
> > let<br>
> > the choice be ours... not as Python developers... but as TripleO<br>
> > deployment developers who choose the write tools for the right<br>
> > jobs.<br>
> ><br>
><br>
> Agreed, we can't deter anyone from editing python anymore than we<br>
> could yaml. <br>
><br>
> But it's not about dictating what people do. It's about what we<br>
> support as a project for users and operators. This is something we<br>
> can define very clearly so that users aren't surprised. At least they<br>
> would have some way of knowing if they are using the system as<br>
> intended.<br>
><br>
> I don't think we should support/encourage editing the yaml workflows<br>
> by end users if we choose a yaml based workflow tool, any more than<br>
> we should support editing python code by users if we wrote our own<br>
> REST API.<br>
><br>
> It's not clear to me in this discussion when the argument about yaml<br>
> files being easier to edit so Mistral/Ansible is a better choice...if<br>
> we're talking about developers editing yaml files, or users editing<br>
> yaml files.<br>
><br>
> 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<br>
> valid argument at all since I view it as something we should never<br>
> do.<br>
<br>
</div></div>/me missed this in his previous reply<br>
<br>
Its both.<br>
<br>
For the latter we want our architecture to be something that users can<br>
"contribute" to. All edits aren't bad. One example: There are some<br>
cases today where we designed our templates as examples (potentially<br>
needing edits). The network configuration templates are an example<br>
here. No harm in adding an extra NIC to a bond or this sort of thing if<br>
the operator/user knows that is how they need to manage their physical<br>
hardware. The smart operator would perhaps build an automatic tool to<br>
help generate these sorts of templates. And perhaps we need a tool to<br>
help generate/validate these templates... but today the lay of the land<br>
is it is okay to customize some of these templates because they were in<br>
fact designed to be customized (os-net-config, etc.)<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace">​What I'm arguing for then is that the distinction and the interface be defined. The reason being that today in tripleo-heat-templates it is not defined and we've left users in limbo. You say the nic config templates are examples, that's fine. But we haven't defined under what circumstances we, as developers, are allowed to make changes that cause people's nic config templates to stop working.<br><br>Either it's an interface that offers stability, or it's not. If we're saying it offers none, personally I disagree with that, but at least we've set the expectation that anytime someone uses a newer tripleo-heat-templates, all bets are off that anything they had working before is expected to still work.​</div><br><div class="gmail_default" style="font-family:monospace,monospace">​How this is relevant to the current conversation is that it appears that some are saying that our yaml workflows would be examples for people to modify, and this is a good reason to choose a yaml based tool over a python one. I disagree with that even being an option.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">Instead, we ought to offer hook or plugin interfaces in our workflows where people can plug in custom workflows as needed. The interface shouldn't require editing any files that TripleO releases. If we get this right, and Mistral already makes it easy for us to get it right, then I think that's a perfectly valid advantage of Mistral over having to write a REST API with equivalent hook/plugin support from scratch.<br></div><br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Dan<br>
</font></span><span class="im HOEnZb"><br>
><br>
>  <br>
> >  ><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>
> > We do totally agree on the stable API part. :)<br>
><br>
> To be clear, are you saying we should have a stable API, and then<br>
> support users in editing the implementation of that API (yaml<br>
> workflows)?<br>
><br>
> For example, we have a stable API such as:<br>
><br>
> POST /workbooks/deploy-cloud/executions<br>
><br>
> that might do totally different things across deployed TripleO clouds<br>
> of the same released version, depending on how the user has<br>
> customized the deploy-cloud workbook?<br>
><br>
> -- <br>
> -- James Slagle<br>
> --<br>
</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:unsubs" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubs</a><br>
> cribe<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>
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><br clear="all"><br>-- <br><div class="gmail_signature">-- James Slagle<br>--</div>
</div></div>