Deprecation notices

This page lists deprecations of Commodore features organized by version. We include a link to relevant documentation, if applicable.

v1.8.0

Parameter -r / --repo-directory for component compile is deprecated

We instead discover the component’s Git repository by recursively searching for a git repository in the component’s parent directories. When the parameter is provided, a deprecation notice is printed and the value of the parameter is discarded.

v1.0.0

  • Support for external postprocessing filter definitions is removed [deprecated in v0.16.0].

  • Support for parameters.component_versions is removed [deprecated in v0.5.0].

  • Deprecated inventory parameters customer.name, cloud.provider, cloud.region and customer.name are removed [deprecated in v0.3.0].

  • Support for component specifications without explicit versions is removed [deprecated in v0.13.0]

  • Support for advertising multi-instance support in component parameter multi_instance is removed [deprecated in v0.14.0].

  • Support for component library names which aren’t prefixed with the component name is removed [deprecated in v0.16.0].

v0.16.0

External postprocessing filter definitions are deprecated

Commodore v0.4.0 introduced support for defining postprocessing filters in the component class. However, defining postprocessing filters in postprocess/filters.yml was never formally deprecated.

To migrate a component which still uses postprocess/filters.yml, you can simply move the contents of the file to parameter commodore.postprocess, remove the file and commit the changes.

component_name=component-name
export filters=$(yq e '.' postprocess/filters.yml)
yq e -i '.parameters.commodore.postprocess = env(filters)' "class/${component_name}.yml"
rm -rf postprocess/
git add -u
git commit -m "Move postprocessing filter definitions to component class"
The provided snippet uses mikefarah/yq v4.

Component library names which aren’t prefixed with the component name are deprecated

Commodore v0.16.0 adds support for explicitly specifying component library aliases. In turn, the previous approach of allowing components to provide libraries with arbitrary names is deprecated. Instead components should always prefix their component libraries with the component name. This introduces namespacing for component libraries by default.

The aliasing mechanism still allows multiple components which implement the same interface to expose their implementation of the shared interface under an arbitrary alias.

Commodore will raise an error if multiple components in the hierarchy try to use the same component library alias.

v0.14.0

Advertising multi-instance support in component parameter multi_instance is deprecated

Commodore v0.14.0 adds support for advertising multi-instance support in components to field multi_instance in the component metadata parameter _metadata. In turn the old location for advertising multi-instance support in component parameter multi_instance is deprecated.

To update existing components, you can simply adjust the component’s class/defaults.yml to match the sample shown below.

parameters:
  <component_name>: (1)
    =_metadata: (2)
      multi_instance: true
1 <component_name> is a placeholder for the component’s parameters key
2 By prefixing the _metadata key with an equals sign, we make the component metadata constant. This ensures that values in _metadata can’t be changed in the hierarchy. See also the Kapitan reclass documentation.
Depending on the age of the component, the metadata key may already exist with empty content.

v0.13.0

parameters.commodore.jsonnet_libs is removed

The parameter has been deprecated since Commodore v0.6.0, and is removed in v0.13.0.

Component specifications without explicit version are deprecated

Users should always specify an explicit version in component specifications. In general, we encourage users to switch to explicitly tagged versions for all components.

To keep the previous default behavior, users can specify version: master in the component specification.

v0.6.0

parameters.commodore.jsonnet_libs is deprecated

Users should specify Jsonnet dependencies of components in the component’s jsonnetfile.json.

For now, Commodore itself ensures kube-libsonnet is available as lib/kube.libsonnet.

v0.5.0

parameters.component_versions is deprecated

Users should switch to parameters.components which has the exact same format.

v0.4.0

  • Class includes of components are removed. Instead components must be included with entries in the applications array.

v0.3.0

  • The reclass hierarchy must be configured in the global defaults repository. See the reference docs for details.

  • The following parameters will be removed in a future release. They’re replaced by keys in parameters.facts and parameters.cluster:

    • parameters.cluster.dist → parameters.facts.distribution

    • parameters.cloud.provider → parameters.facts.cloud

    • parameters.cloud.region → parameters.facts.region

    • parameters.customer.name → parameters.cluster.tenant

v0.2.0