<div dir="ltr">I have to agree - I prefer the minimal approach of option 2. It keeps the kolla-ansible code base small and easy to understand. The required test matrix is therefore relatively small (although better coverage of services in CI would be good). Finally, the approach has allowed the project to move quickly and support deployment of many OpenStack projects.<div><br></div><div>Customised options shouldn't be outlawed though. There are times when they are very useful and/or required:</div><div><br></div><div>* some things that cannot be expressed in config files alone</div><div>* some options apply to many/all services (sometimes with subtle differences in configuration)</div><div>* some config files are not in a format that can be easily merged (HAProxy, dnsmasq, etc.)</div><div><br></div><div>These should be the exception, rather than the rule, however.</div><div><br></div><div>Mark</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 29 January 2018 at 14:12, Jeffrey Zhang <span dir="ltr"><<a href="mailto:zhang.lei.fly@gmail.com" target="_blank">zhang.lei.fly@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Thank Paul for pointing this out.</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">for me, I prefer to consist with 2)</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">There are thousands of configuration in OpenStack, it is hard for Kolla to</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">add every key/value pair in playbooks. Currently, the merge_config is a more</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">better solutions. </div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke <span dir="ltr"><<a href="mailto:paul.bourke@oracle.com" target="_blank">paul.bourke@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I'd like to revisit our policy of not templating everything in kolla-ansible's template files. This is a policy that was set in place very early on in kolla-ansible's development, but I'm concerned we haven't been very consistent with it. This leads to confusion for contributors and operators - "should I template this and submit a patch, or do I need to start using my own config files?".<br>
<br>
The docs[0] are currently clear:<br>
<br>
"The Kolla upstream community does not want to place key/value pairs in the Ansible playbook configuration options that are not essential to obtaining a functional deployment."<br>
<br>
In practice though our templates contain many options that are not necessary, and plenty of patches have merged that while very useful to operators, are not necessary to an 'out of the box' deployment.<br>
<br>
So I'd like us to revisit the questions:<br>
<br>
1) Is kolla-ansible attempting to be a 'batteries included' tool, which caters to operators via key/value config options?<br>
<br>
2) Or, is it to be a solid reference implementation, where any degree of customisation implies a clear 'bring your own configs' type policy.<br>
<br>
If 1), then we should potentially:<br>
<br>
* Update ours docs to remove the referenced paragraph<br>
* Look at reorganising files like globals.yml into something more maintainable.<br>
<br>
If 2),<br>
<br>
* We should make it clear to reviewers that patches templating options that are non essential should not be accepted.<br>
* Encourage patches to strip down existing config files to an absolute minimum.<br>
* Make this policy more clear in docs / templates to avoid frustration on the part of operators.<br>
<br>
Thoughts?<br>
<br>
Thanks,<br>
-Paul<br>
<br>
[0] <a href="https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization" rel="noreferrer" target="_blank">https://docs.openstack.org/kol<wbr>la-ansible/latest/admin/deploy<wbr>ment-philosophy.html#why-not-t<wbr>emplate-customization</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_-6200464023758592195gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-size:13px;border-collapse:collapse"><font face="monospace, monospace">Regards,</font></span></div><div><span style="font-size:13px;border-collapse:collapse"><font face="monospace, monospace">Jeffrey Zhang</font></span></div><div><span style="font-family:monospace,monospace;font-size:12.8px">Blog: </span><a href="http://xcodest.me/" style="font-family:monospace,monospace;font-size:12.8px" target="_blank">http://xcodest.me</a><font face="monospace, monospace"><br></font></div></div></div></div></div></div></div></div></div>
</font></span></div>
<br>______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>