Open Stack

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