ConfigurationSlice

The ConfigurationSlice custom resource for Application Configuration Service refers to an existing ConfigurationSource to describe one or more subsets, or slices, of configuration to get from configuration repositories defined in the ConfigurationSource. The configuration creates secrets by default, with an option to use configMaps for unencrypted properties.

KIND:     ConfigurationSlice
VERSION:  config.apps.tanzu.vmware.com/v1alpha4

RESOURCE: spec <Object>

DESCRIPTION:
     A configuration slice custom resource (CR) describes one or more subsets,
     or slices, of configuration to obtain from the repositories defined in the
     ConfigurationSource.

FIELDS:
   configMapName	<string>
     The name to give the ConfigMap created from this ConfigurationSlice.
     Defaults to the same name as the ConfigurationSlice

     Important: The configMapName should be unique. If there are two or more
     mutable ConfigurationSlices (e.g., mutable = "true") in the same
     namespace, they will each overwrite the values in the same ConfigMap. What's
     more, if the slices have interval set, they will periodically overwrite
     each other's values, creating a continuously changing ConfigMap.

   configMapStrategy	<string>
     Can be a value of "tree" or "applicationProperties". If “tree”, then
     create a ConfigMap with one property per property found in the
     provider/slice combination. If “applicationProperties”, create a
     ConfigMap and/or Secret with a single property named
     “application.properties” whose value is a properties file structure.
     This is to allow applications that do not support configuration tree
     volume mounts, such as applications built with versions of Spring Boot
     prior to Spring Boot 2.4.

   configurationSource	<string>
     The name of the ConfigurationSource resource that define the backends this
     ConfigurationSlice will pull its configuration from.

   content	<[]string>
     A list of entries defining the subset of properties to pull from the
     backends in the ConfigurationSource. The default value is
     "application/default".

   createSecretsOnly	<boolean>
     If false, Secrets will be created the Configuration Slice only when
     encrypted entries exist otherwise only a ConfigMap is created. The default
     value is true.

   interval	<string>
     Defines the refresh interval for checking the underlying backend
     repositories for changes. The value must be in a Go recognized duration
     string format, e.g. 10m0s to reconcile the object every 10 minutes.

     Important: The interval only specifies how frequently the backend repositories
     are polled for updates. If an update is found, the ConfigMap/Secret will
     be updated relatively quickly. But it may take up to 2 minutes before the
     filesystem on the application pod is synched to reflect the new properties
     and values. This is because of the cluster's kubelet sync period and and the
     ConfigMap/Secret TTL cache, which are typically set at 1 minute each.

   mutable	<boolean>
     If true, create a mutable ConfigMap and/or Secret with no suffix attached
     to the name. Otherwise, create an immutable ConfigMap and/or Secret, with a
     unique hash suffix on the name. The default value is false.

   secretName	<string>
     The name to give to the Secret created. Defaults to the same name as the
     ConfigurationSlice.

     Important: The secretName should be unique. If there are two or more
     mutable ConfigurationSlices (e.g., mutable = "true") in the same
     namespace, they will each overwrite the values in the same Secret. What's
     more, if the slices have interval set, they will periodically overwrite
     each other's values, creating a continuously changing Secret.

   secretStrategy	<string>
     Can be a value of "tree" or "applicationProperties". If “tree”, then
     create a Secret with one property per property found in the provider/slice
     combination. If “applicationProperties”, create a ConfigMap and/or
     Secret with a single property named “application.properties” whose
     value is a properties file structure. This is to allow applications that
     do not support configuration tree volume mounts, such as applications built
     with versions of Spring Boot prior to Spring Boot 2.4.

ConfigMap and Secret Strategy

By default, ConfigMaps and Secrets are created to support configuration tree volume mounts. This means that there will be one entry for each property written to the ConfigMap/Secret.

For example, if the source Git repository has two properties named "cook.special" and "cook.appetizer", a resulting ConfigMap might look like this when inspected by kubectl describe:

    Name:         cook-config-slice
    Namespace:    my-app-ns
    Labels:       configslice.name=cook-config-slice
          configslice.namespace=my-app-ns
    Annotations:  <none>

    Data
    ====
    cook.special:
    ----
    Cake a la mode
    cook.appetizer:
    ----
    Fried pickles

As a consequence of this one-entry-per-property structure, when the ConfigMap or Secret is mounted onto a pod's filesystem, there will be one file per property where each file's name is the same as the property name and each file's content is the property's value.

However, if the slice's configMapStrategy and/or secretStrategy is set to "applicationProperties", there will instead be a single entry named "application. properties" in the resulting ConfigMap/Secret. Given the same two properties as above, a ConfigMap might look like this:

    Name:         cook-config-slice
    Namespace:    my-app-ns
    Labels:       configslice.name=cook-config-slice
          configslice.namespace=my-app-ns
    Annotations:  <none>

    Data
    ====
    application.properties:
    ----
    cook.special=Cake a la mode
    cook.appetizer=Fried pickles

When mounted on a pod's filesystem, there will be a single file named "application.properties" that contains all of the properties.

v1alpha3 API

v1alpha3 has been deprecated, please migrate to v1alpha4. For details about the v1alpha3 ConfigurationSlice resource, see its documentation in the previous release.

ConfigurationSlice Content

Configuration content entries are made up of three components:

{APP NAME}/{PROFILE NAME}/{LABELS}

• {APP NAME} — The name of an application for which the configuration is being retrieved. If “application”, then this is considered the default application and includes configuration shared across multiple applications. Any other value specifies a specific application and will include properties for both the specified application as well as shared properties for the default application.

• {PROFILE NAME} — The name of a profile for which properties may be retrieved. If “default” or “*”, then this includes properties that are shared across any all profiles. If any non-default value, then the slice will include properties for the specified profile as well as properties for the default profile.

• {LABELS} — An optional comma-separated list of labels from which to retrieve properties. If not specified, then the default is to pull properties from a branch named main. If specified, then properties will be retrieved from all listed labels, but not from the main branch (unless it is included in the list).

In this example ConfigurationSlice:

apiVersion: "config.apps.tanzu.vmware.com/v1alpha4"
kind: ConfigurationSlice
metadata:
  name: cook-config-slice
spec:
  configurationSource: cook-config-source
  immutable: false
  content:
  - cook/production
  - cook/default

So with the given content entries, these will resolve to the files cook-production.[yml|properties], cook.[yml|properties], and application.[yml|properties] on the default branch configured on the referenced ConfigurationSource. Configuration properties are given precedence to earlier items in the content list - ie. if the same configuration property exists in all three files, then the value in cook-production will be in the resulting Secret resource.