[openstack-dev] [kolla] Policy regarding template customisation
harlowja at fastmail.com
Tue Jan 30 17:34:05 UTC 2018
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
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:
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?
Perhaps I can go into more detail if it seems like one others may want
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
More information about the OpenStack-dev