feat: provide flexible operator overrides for all OpenStack configuration templates

[alanmeadows]

This is a large feature that attempts to solve several critical items to make this project useful for real deployments:

1. Charts need a consistent and reliable way to offer operators the option to override configuration file settings. For instance, if the operator knows they want to change the debug value in the [DEFAULT] section in nova.conf, what do they provide to helm install --set or in their own --values overrides, whether on the command line or in a large environment wide YAML. Today, they would need to go inspect the chart and its templates to determine what this value is. The proposal here would make this consistent, allowing the operator, once they understand the pattern to simply say helm install local/nova --set conf.nova_conf.default.debug=true

2. Operators need to be able to override more parameters then we supply in our configuration files today. We provide a very small subset of the overall knobs OpenStack has. The proposal here would take the upstream configuration files for a service, and pull those in as our starting template. We would then take every parameter in that file, and ensure that each line is something like:

[api_database]
mysql_sql_mode = `.Values.conf.nova_conf.api_database.mysql_sql_mode | default 'TRADITIONAL'

3. We should provide operators with the ability to arbitrary add lines at the end of any section by adding text to the following attribute:

.Values.conf.nova_conf.api_database.misc

4. We want to support operators providing their own pre-baked configuration files without having to fork our charts. This means we would support the operator passing us their nova.conf verbatim. Every template will need to begin with either using this (if its not nil) or using our standard out of the box template.

.Values.conf.nova_conf.override = """My raw config file"""

5. We want to provide operators the ability to arbitrary inject new files that our charts may not account for. This means we need to refactor our configmaps across all charts to leverage values.yaml to understand what mounts to perform on what container. This will also allow us to explicitly define read-only and ownership attriibutes as part of this effort. With this in place, operators can inject additional mounts for nova-api for instance, if they need a /etc/nova/my-custom-file.conf

6. We will ensure all charts have all required files, including items like policy.json, api-paste.json and other ancilliary files so that any underlying image can be used that may or may not contain these dependencies. Today, we have a needless reliance on them which also makes them immutable for the operator as they are baked into the image.

7. As part of this effort, and to satisfy items (2) and (3) above, we should evaluate developing or looking at oslo-gen-config to help pull down the configuration from upstream and generate a template with the | default entries. This will allow us to rapidly change our templates when we switch from a newton target, for instance, to ocata

[alanmeadows]

@intlabs @v1k0d3n @DTadrzak @wilkers-steve

[wilreichert]

I like 2 / 3 / 7, but attempting to set defaults for every value would difficult. Maybe better to exclude anything not explicitly set?

{{ with .Values.conf.nova_conf.api_database.mysql_sql_mode -}} mysql_sql_mode = .Values.conf.nova_conf.api_database.mysql_sql_mode {{- end }}

and only include the minimum set of values in values.yaml to get a system running.

[intlabs]

Alan's been working on a prototype for this that implements the precise functionality you describe but slightly differently. Rather than commenting the line in if a value is set, we have been experimenting with commenting the comment delimiter out if a value is set. This is much better explained in code than words:

{{ if not .Values.conf.keystone.admin_token }}#{{ end }}admin_token = {{ .Values.conf.keystone.admin_token | default "<None>" }}

The advantage of this approach we hope is that it allows the resultant configuration file to be much more readable, include the comments inserted by oslo-gen-config and indicate the path of the key that can be used to set it whilst also retaining the default values, e.g.

# Limit the sizes of user & project ID/names. (integer value)
# from .Values.conf.keystone.max_param_size
{{ if not .Values.conf.keystone.max_param_size }}#{{ end }}max_param_size = {{ .Values.conf.keystone.max_param_size | default "64" }}