[openstack-dev] [kolla] Policy regarding template customisation
inc007 at gmail.com
Tue Jan 30 18:38:13 UTC 2018
On 30 January 2018 at 09:34, Joshua Harlow <harlowja at fastmail.com> wrote:
> I'm ok with #2,
> Though I would like to show an alternative that we have been experimenting
> with that avoids the whole needs for a globals.yml and such files in the
> first place (and feels more naturally inline with how ansible works IMHO).
> So short explanation first; we have this yaml format that describes all of
> our clouds and there settings and such (and which servers belong in which
> cloud and so on and so forth). We have then setup a REST server (small
> gunicorn based one) that renders/serves this format into other formats.
> One of those other formats is one that is compatible with ansibles concept
> of dynamic inventory  and that is the one we are trying to send into
> kolla-ansible to get it to configure all the things (via typical mechanisms
> such as hostvars and groupvars).
> An example of this rendering:
> https://gist.github.com/harlowja/9d7b57571a2290c315fc9a4bf2957dac (this is
> dynamically generated from the other format, which is git version
> The goal here is that we can just render all the needed variables and such
> for kolla-ansible (at a per-host basis if we have to) and avoid the need for
> having a special globals.yml (per-cloud/environment) and per-host special
> files in the first place.
> Was this kind of approach ever thought of?
Well that totally works:)
I routinely use inventory to override parts of globals (different
iface per node). You could have [all:vars] section in inventory and
set every variable usually set in globals there. However I think issue
here is about files in /etc/kolla/config - so config overrides.
I think one potential solution would be to have some sort of ansible
task that would translate ansible vars to ini format and lay down
files in /etc/kolla/config, but I think that's beyond scope of
> Perhaps I can go into more detail if it seems like one others may want to
> : http://docs.ansible.com/ansible/latest/intro_dynamic_inventory.html
> Paul Bourke 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 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
>> 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
>> * Make this policy more clear in docs / templates to avoid frustration
>> on the part of operators.
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev