[openstack-dev] [kolla] Policy regarding template customisation
simon.leinen at switch.ch
Tue Jan 30 12:54:19 UTC 2018
Paul Bourke writes:
> So I think everyone is in agreement that it should be option 2. I'm
> leaning towards this also but I'm wondering how much of this makes
> things easier for us as developers rather than operators.
> How committed this are we in practice? For example, if we take
> nova.conf, if we follow option 2, theoretically all alternate
> hypervisor options (vmware/xen/nova-fake) etc. should come out and be
> left to override files. As should options templating options such as
> metadata_workers, listen ports, etc. globals.yml could probably be
> half the size it currently is. But if we go this route how many
> operators will stick with kolla? [...]
Operator here. I've been following this discussion. Background: We
have been using puppet-openstack combined with our own Puppet
"integration classes" for several years. All configuration parameters
are neatly in Hiera. So we're used to the "batteries-included" way that
Paul describes under (1). For various reasons, we are also looking at
new ways of provisioning our control plane, including Kolla.
In hindsight, and in my personal opinion, while our previous approach
(1) has somehow felt like the proper way to do things, it hasn't really
paid off for us as an operator, and I would happily try approach (2).
The perceived downside of (2) - or a perceived advantage of (1) - is
that in an ideal world, (1) isolates us from the arcane configuration
file details that the crazy devs of individual services come up with.
In practice, it turns out that (a) those files aren't rocket science (b)
as an operator you need to understand them anyway, at the latest when
you need to debug stuff, and (c) the deployment tool can easily become a
bottlenecks for deploying new features.
This is why I'm happy to embrace the current Kolla philosophy (2).
Sorry if I'm just repeating arguments that led to its adoption in the
first place - I wasn't there when that happened.
> Maybe it won't be a big deal, the issue currently is the line is
> blurred on what gets templated and what doesn't.
More information about the OpenStack-dev