We add 2 features to the sidecar injector to make use at scale more ergonomic. 1) versioned configurations and 2) inheritance.
Versioning
We found ourselves suffixing the names of sidecars with versioning information, so we could make improvements to sidecars without breaking legacy consumers of a given sidecar. For example, we would name configs name: some-sidecar-v3. To codify this behavior without changing the request interface, we add support for versioned sidecar configurations, similar to how Docker images work.
By changing nothing in your configs, each sidecar configuration now has a Version() which is derived by splitting off the last field after :. By default, this is latest. Here are some examples of name: fields, and the derived version.
my-sidecar -> latest
my-sidecar:latest -> latest
my-sidecar:v420 -> v420
my-sidecar:extra:fields:6.9 -> 6.9
This change allows you to maintain versioned configs, as well as "symlink" consumers to the latest version of a sidecar, via :latest.
Inheritance
In addition to versioning, we have found that a lot of our sidecar configurations are actually quite similar, and tend to have only a few differences. This brought us to build inheritance functionality into the configs. By introducing an inherits: field to configs loaded from disk (not ConfigMaps!), we support a config using a base, and merging in any fields from the child as necessary.
Note: some (most) fields in the config format are sets, so we must perform merging in a manner that provides set uniqueness by name field.
For example, a config like the following would load another.yaml, and then add 2 env vars to it. If EXISTING_VAR exists in another.yaml, it will be replaced. NEW_VAR, if not appearing in the env list, will be appended. All configs referenced via inherits: are relative to the directory of the parent file, and cannot traverse upwards in the directory.
What and why?
We add 2 features to the sidecar injector to make use at scale more ergonomic. 1) versioned configurations and 2) inheritance.
Versioning
We found ourselves suffixing the names of sidecars with versioning information, so we could make improvements to sidecars without breaking legacy consumers of a given sidecar. For example, we would name configs
name: some-sidecar-v3. To codify this behavior without changing the request interface, we add support for versioned sidecar configurations, similar to how Docker images work.By changing nothing in your configs, each sidecar configuration now has a
Version()which is derived by splitting off the last field after:. By default, this islatest. Here are some examples ofname:fields, and the derivedversion.my-sidecar->latestmy-sidecar:latest->latestmy-sidecar:v420->v420my-sidecar:extra:fields:6.9->6.9This change allows you to maintain versioned configs, as well as "symlink" consumers to the latest version of a sidecar, via
:latest.Inheritance
In addition to versioning, we have found that a lot of our sidecar configurations are actually quite similar, and tend to have only a few differences. This brought us to build inheritance functionality into the configs. By introducing an
inherits:field to configs loaded from disk (notConfigMaps!), we support a config using a base, and merging in any fields from the child as necessary.Note: some (most) fields in the config format are sets, so we must perform merging in a manner that provides set uniqueness by
namefield.For example, a config like the following would load
another.yaml, and then add 2 env vars to it. IfEXISTING_VARexists inanother.yaml, it will be replaced.NEW_VAR, if not appearing in theenvlist, will be appended. All configs referenced viainherits:are relative to the directory of the parent file, and cannot traverse upwards in the directory.Testing Steps
make test)Reviewers
Required reviewers:
@byxornaRequest reviews from other people you want to review this PR in the "Reviewers" section on the right.