Hey, So I'm also for option 2. There was big discussion in Atlanta about "how hard it is to keep configs up to date and remove deprecated options". merge_config makes it easier for us to handle this. With amount of services we support I don't think we have enough time to keep tabs on every config change across OpenStack.
On 29 January 2018 at 08:03, Steven Dake (stdake) <std...@cisco.com> wrote: > Agree, the “why” of this policy is stated here: > > https://docs.openstack.org/developer/kolla-ansible/deployment-philosophy.html > > > > Paul, I think your corrective actions sound good. Perhaps we should also > reword “essential” to some other word that is more lenient. > > > > Cheers > > -steve > > > > From: Jeffrey Zhang <zhang.lei....@gmail.com> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: Monday, January 29, 2018 at 7:14 AM > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [kolla] Policy regarding template customisation > > > > Thank Paul for pointing this out. > > > > for me, I prefer to consist with 2) > > > > There are thousands of configuration in OpenStack, it is hard for Kolla to > > add every key/value pair in playbooks. Currently, the merge_config is a more > > better solutions. > > > > > > > > > > On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke <paul.bou...@oracle.com> wrote: > > Hi all, > > 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?". > > The docs[0] are currently clear: > > "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." > > 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. > > So I'd like us to revisit the questions: > > 1) Is kolla-ansible attempting to be a 'batteries included' tool, which > caters to operators via key/value config options? > > 2) Or, is it to be a solid reference implementation, where any degree of > customisation implies a clear 'bring your own configs' type policy. > > If 1), then we should potentially: > > * Update ours docs to remove the referenced paragraph > * Look at reorganising files like globals.yml into something more > maintainable. > > If 2), > > * We should make it clear to reviewers that patches templating options that > are non essential should not be accepted. > * Encourage patches to strip down existing config files to an absolute > minimum. > * Make this policy more clear in docs / templates to avoid frustration on > the part of operators. > > Thoughts? > > Thanks, > -Paul > > [0] > https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization > > __________________________________________________________________________ > 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 > > > > > > -- > > Regards, > > Jeffrey Zhang > > Blog: http://xcodest.me > > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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
