On 30 January 2018 at 09:34, Joshua Harlow <harlo...@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 [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?
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 Kolla-Ansible. > > 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 __________________________________________________________________________ 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