Open Stack

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 [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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev