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 [1] 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
controlled...).
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
to follow....
[1]: 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[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
__________________________________________________________________________
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