So I think everyone is in agreement that it should be option 2. I'm
leaning towards this also but I'm wondering how much of this makes
things easier for us as developers rather than operators.
How committed this are we in practice? For example, if we take
nova.conf[0], if we follow option 2, theoretically all alternate
hypervisor options (vmware/xen/nova-fake) etc. should come out and be
left to override files. As should options templating options such as
metadata_workers, listen ports, etc. globals.yml could probably be half
the size it currently is. But if we go this route how many operators
will stick with kolla? Maybe it won't be a big deal, the issue currently
is the line is blurred on what gets templated and what doesn't.
On 30/01/18 01:04, Michał Jastrzębski wrote:
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
__________________________________________________________________________
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
