The name of the process.

"dotenv"

"hcl"

"ini"

"json"

"properties"

"props-plus"

"props-ultra"

"redis"

"toml"

"xml"

"yaml"

Specifies the config file name in the config template.

Specifies the name of the referenced componentTemplateSpec.

Specifies the format of the configuration file and any associated parameters that are specific to the chosen format. Supported formats include ini, xml, yaml, json, hcl, dotenv, properties, and toml.

Each format may have its own set of parameters that can be configured. For instance, when using the ini format, you can specify the section name.

Example:

fileFormatConfig:
 format: ini
 iniConfig:
   sectionName: mysqld

Specifies whether the configuration needs to be re-rendered after v-scale or h-scale operations to reflect changes.

In some scenarios, the configuration may need to be updated to reflect the changes in resource allocation or cluster topology. Examples:

• Redis: adjust maxmemory after v-scale operation.
• MySQL: increase max connections after v-scale operation.
• Zookeeper: update zoo.cfg with new node addresses after h-scale operation.

Specifies the name of the Cluster that this configuration is associated with.

Represents the name of the Component that this configuration pertains to.

ConfigItemDetails is an array of ConfigTemplateItemDetail objects.

Each ConfigTemplateItemDetail corresponds to a configuration template, which is a ConfigMap that contains multiple configuration files. Each configuration file is stored as a key-value pair within the ConfigMap.

The ConfigTemplateItemDetail includes information such as:

• The configuration template (a ConfigMap)
• The corresponding ConfigConstraint (constraints and validation rules for the configuration)
• Volume mounts (for mounting the configuration files)

Provides a description of any abnormal status.

Indicates the current status of the configuration item.

Possible values include “Creating”, “Init”, “Running”, “Pending”, “Merged”, “MergeFailed”, “FailedAndPause”, “Upgrading”, “Deleting”, “FailedAndRetry”, “Finished”.

Represents the latest generation observed for this ClusterDefinition. It corresponds to the ConfigConstraint’s generation, which is updated by the API Server.

Provides detailed status information for opsRequest.

Provides the status of each component undergoing reconfiguration.

Specifies the name of the Component.

Specifies the user-defined configuration template or parameters.

Specifies the user-defined configuration template.

When provided, the importTemplateRef overrides the default configuration template specified in configSpec.templateRef. This allows users to customize the configuration template according to their specific requirements.

Specifies the name of the Component.

Indicates the current status of the configuration item.

Possible values include “Creating”, “Init”, “Running”, “Pending”, “Merged”, “MergeFailed”, “FailedAndPause”, “Upgrading”, “Deleting”, “FailedAndRetry”, “Finished”.

Describes the status of the component reconfiguring.

Specifies the name of the referenced configuration template ConfigMap object.

Specifies the namespace of the referenced configuration template ConfigMap object. An empty namespace is equivalent to the “default” namespace.

Defines the strategy for merging externally imported templates into component templates.

Defines the unique identifier of the configuration template.

It must be a string of maximum 63 characters, and can only include lowercase alphanumeric characters, hyphens, and periods. The name must start and end with an alphanumeric character.

External controllers can trigger a configuration rerender by modifying this field.

Note: Currently, the payload field is opaque and its content is not interpreted by the system. Modifying this field will cause a rerender, regardless of the specific content of this field.

Specifies the name of the configuration template (a ConfigMap), ConfigConstraint, and other miscellaneous options.

The configuration template is a ConfigMap that contains multiple configuration files. Each configuration file is stored as a key-value pair within the ConfigMap.

ConfigConstraint allows defining constraints and validation rules for configuration parameters. It ensures that the configuration adheres to certain requirements and limitations.

Specifies the user-defined configuration template.

When provided, the importTemplateRef overrides the default configuration template specified in configSpec.templateRef. This allows users to customize the configuration template according to their specific requirements.

Specifies the user-defined configuration parameters.

When provided, the parameter values in configFileParams override the default configuration parameters. This allows users to override the default configuration according to their specific needs.

Specifies the name of the configuration template. It is a required field and must be a string of maximum 63 characters. The name should only contain lowercase alphanumeric characters, hyphens, or periods. It should start and end with an alphanumeric character.

Indicates the current status of the configuration item.

Possible values include “Creating”, “Init”, “Running”, “Pending”, “Merged”, “MergeFailed”, “FailedAndPause”, “Upgrading”, “Deleting”, “FailedAndRetry”, “Finished”.

Represents the last completed revision of the configuration item. This field is optional.

Represents the updated revision of the configuration item. This field is optional.

Provides a description of any abnormal status. This field is optional.

Provides detailed information about the execution of the configuration change. This field is optional.

Specifies the name of the field. It must be a string of maximum length 63. The name should match the regex pattern ^[a-z0-9]([a-z0-9\.\-]*[a-z0-9])?$.

Specifies the mount point of the Downward API volume.

Represents a list of files under the Downward API volume.

Specifies the command to be triggered when changes are detected in Downward API volume files. It relies on the inotify mechanism in the config-manager sidecar to monitor file changes.

ScriptConfig object specifies a ConfigMap that contains script files that should be mounted inside the pod. The scripts are mounted as volumes and can be referenced and executed by the DownwardAction to perform specific tasks or configurations.

"all"

"dynamic"

"auto"

"http"

"sql"

"exec"

"tpl"

"signal"

(Members of FormatterAction are embedded into this type.)

Each format may have its own set of parameters that can be configured. For instance, when using the ini format, you can specify the section name.

The config file format. Valid values are ini, xml, yaml, json, hcl, dotenv, properties and toml. Each format has its own characteristics and use cases.

• ini: is a text-based content with a structure and syntax comprising key–value pairs for properties, reference wiki: https://en.wikipedia.org/wiki/INI_file
• xml: refers to wiki: https://en.wikipedia.org/wiki/XML
• yaml: supports for complex data types and structures.
• json: refers to wiki: https://en.wikipedia.org/wiki/JSON
• hcl: The HashiCorp Configuration Language (HCL) is a configuration language authored by HashiCorp, reference url: https://www.linode.com/docs/guides/introduction-to-hcl/
• dotenv: is a plain text file with simple key–value pairs, reference wiki: https://en.wikipedia.org/wiki/Configuration_file#MS-DOS
• properties: a file extension mainly used in Java, reference wiki: https://en.wikipedia.org/wiki/.properties
• toml: refers to wiki: https://en.wikipedia.org/wiki/TOML
• props-plus: a file extension mainly used in Java, supports CamelCase(e.g: brokerMaxConnectionsPerIp)

Holds options specific to the ‘ini’ file format.

A string that describes the name of the ini section.

"none"

"add"

"patch"

"replace"

Specifies the ComponentDefinition custom resource (CR) that defines the Component’s characteristics and behavior.

ServiceVersion specifies the version of the Service expected to be provisioned by this Component. The version should follow the syntax and semantics of the “Semantic Versioning” specification (http://semver.org/). If no version is specified, the latest available version will be used.

Specifies the ParametersDefinition custom resource (CR) that defines the Component parameter’s schema and behavior.

Specifies the configuration files.

The most recent generation number of the ParamsDesc object that has been observed by the controller.

Provides additional information about the current phase.

Specifies the status of the configuration template. When set to PDAvailablePhase, the ParamsDesc can be referenced by ComponentDefinition.

"RestoreToDefault"

"Reset"

Specifies the method to handle the deletion of a parameter. If set to “RestoreToDefault”, the parameter will be restored to its default value, which requires engine support, such as pg. If set to “Reset”, the parameter will be re-rendered through the configuration template.

Specifies the value to use if DeletedMethod is RestoreToDefault. Example: pg SET configuration_parameter TO DEFAULT;

"Creating"

"Deleting"

"FailedAndPause"

"FailedAndRetry"

"Finished"

"Init"

"MergeFailed"

"Merged"

"Pending"

"Running"

"Upgrading"

Specifies the name of the Cluster resource that this operation is targeting.

Lists ComponentParametersSpec objects, each specifying a Component and its parameters and template updates.

Provides a description of any abnormal status.

Indicates the current status of the configuration item.

Possible values include “Creating”, “Init”, “Running”, “Pending”, “Merged”, “MergeFailed”, “FailedAndPause”, “Upgrading”, “Deleting”, “FailedAndRetry”, “Finished”.

Represents the latest generation observed for this ClusterDefinition. It corresponds to the ConfigConstraint’s generation, which is updated by the API Server.

Records the status of a reconfiguring operation if opsRequest.spec.type equals to “Reconfiguring”.

Specifies the config file name in the config template.

Defines a list of parameters including their names, default values, descriptions, types, and constraints (permissible values or the range of valid values).

Specifies the dynamic reload (dynamic reconfiguration) actions supported by the engine. When set, the controller executes the scripts defined in these actions to handle dynamic parameter updates.

Dynamic reloading is triggered only if both of the following conditions are met:

1. The modified parameters are listed in the dynamicParameters field. If dynamicParameterSelectedPolicy is set to “all”, modifications to staticParameters can also trigger a reload.
2. reloadAction is set.

If reloadAction is not set or the modified parameters are not listed in dynamicParameters, dynamic reloading will not be triggered.

Example:

dynamicReloadAction:
 tplScriptTrigger:
   namespace: kb-system
   scriptConfigMapRef: mysql-reload-script
   sync: true

Specifies a list of actions to execute specified commands based on Pod labels.

It utilizes the K8s Downward API to mount label information as a volume into the pod. The ‘config-manager’ sidecar container watches for changes in the role label and dynamically invoke registered commands (usually execute some SQL statements) when a change is detected.

It is designed for scenarios where:

• Replicas with different roles have different configurations, such as Redis primary & secondary replicas.
• After a role switch (e.g., from secondary to primary), some changes in configuration are needed to reflect the new role.

Specifies the policy when parameter be removed.

Indicates whether to consolidate dynamic reload and restart actions into a single restart.

• If true, updates requiring both actions will result in only a restart, merging the actions.
• If false, updates will trigger both actions executed sequentially: first dynamic reload, then restart.

This flag allows for more efficient handling of configuration changes by potentially eliminating an unnecessary reload step.

Configures whether the dynamic reload specified in reloadAction applies only to dynamic parameters or to all parameters (including static parameters).

• false (default): Only modifications to the dynamic parameters listed in dynamicParameters will trigger a dynamic reload.
• true: Modifications to both dynamic parameters listed in dynamicParameters and static parameters listed in staticParameters will trigger a dynamic reload. The “all” option is for certain engines that require static parameters to be set via SQL statements before they can take effect on restart.

List static parameters. Modifications to any of these parameters require a restart of the process to take effect.

List dynamic parameters. Modifications to these parameters trigger a configuration reload without requiring a process restart.

Lists the parameters that cannot be modified once set. Attempting to change any of these parameters will be ignored.

The most recent generation number of the ParamsDesc object that has been observed by the controller.

Specifies the status of the configuration template. When set to PDAvailablePhase, the ParamsDesc can be referenced by ComponentDefinition.

Represents a list of detailed status of the ParametersDescription object.

This field is crucial for administrators and developers to monitor and respond to changes within the ParametersDescription. It provides a history of state transitions and a snapshot of the current state that can be used for automated logic or direct inspection.

"Available"

"Deleting"

"Unavailable"

Holds the configuration keys and values. This field is a workaround for issues found in kubebuilder and code-generator. Refer to https://github.com/kubernetes-sigs/kubebuilder/issues/528 and https://github.com/kubernetes/code-generator/issues/50 for more details.

Represents the content of the configuration file.

Represents the updated parameters for a single configuration file.

Specifies the top-level key in the ‘configSchema.cue’ that organizes the validation rules for parameters. This key must exist within the CUE script defined in ‘configSchema.cue’.

Hold a string that contains a script written in CUE language that defines a list of configuration items. Each item is detailed with its name, default value, description, type (e.g. string, integer, float), and constraints (permissible values or the valid range of values).

CUE (Configure, Unify, Execute) is a declarative language designed for defining and validating complex data configurations. It is particularly useful in environments like K8s where complex configurations and validation rules are common.

This script functions as a validator for user-provided configurations, ensuring compliance with the established specifications and constraints.

Generated from the ‘cue’ field and transformed into a JSON format.

Represents the policy applied during the most recent execution.

Represents the outcome of the most recent execution.

Represents the current revision of the configuration item.

Represents the number of pods where configuration changes were successfully applied.

Represents the total number of pods that require execution of configuration changes.

Represents the error message generated when the execution of configuration changes fails.

(Members of ConfigTemplateItemDetailStatus are embedded into this type.)

Contains the updated parameters.

Specifies the user-defined configuration template.

When provided, the importTemplateRef overrides the default configuration template specified in configSpec.templateRef. This allows users to customize the configuration template according to their specific requirements.

Used to trigger a reload by sending a specific Unix signal to the process.

Allows to execute a custom shell script to reload the process.

Enables reloading process using a Go template script.

Automatically perform the reload when specified conditions are met.

Used to match labels on the pod to determine whether a dynamic reload should be performed.

In some scenarios, only specific pods (e.g., primary replicas) need to undergo a dynamic reload. The reloadedPodSelector allows you to specify label selectors to target the desired pods for the reload process.

If the reloadedPodSelector is not specified or is nil, all pods managed by the workload will be considered for the dynamic reload.

"asyncReload"

"dynamicReloadBeginRestart"

"none"

"restartContainer"

"restart"

"rolling"

"syncReload"

"hscale"

"tls"

"vscale"

"shardingHScale"

Specifies the reference to the ConfigMap containing the scripts.

Specifies the namespace for the ConfigMap. If not specified, it defaults to the “default” namespace.

Specifies the command to execute in order to reload the process. It should be a valid shell command.

Determines the synchronization mode of parameter updates with “config-manager”.

• ‘True’: Executes reload actions synchronously, pausing until completion.
• ‘False’: Executes reload actions asynchronously, without waiting for completion.

Controls whether parameter updates are processed individually or collectively in a batch:

• ‘True’: Processes all changes in one batch reload.
• ‘False’: Processes each change individually.

Defaults to ‘False’ if unspecified.

Specifies a Go template string for formatting batch input data. It’s used when batchReload is ‘True’ to format data passed into STDIN of the script. The template accesses key-value pairs of updated parameters via the ‘$’ variable. This allows for custom formatting of the input data.

Example template:

batchParamsFormatterTemplate: |-
{{- range $pKey, $pValue := $ }}
{{ printf "%s:%s" $pKey $pValue }}
{{- end }}

This example generates batch input data in a key:value format, sorted by keys.

key1:value1
key2:value2
key3:value3

If not specified, the default format is key=value, sorted by keys, for each updated parameter.

key1=value1
key2=value2
key3=value3

Specifies the tools container image used by ShellTrigger for dynamic reload. If the dynamic reload action is triggered by a ShellTrigger, this field is required. This image must contain all necessary tools for executing the ShellTrigger scripts.

Usually the specified image is referenced by the init container, which is then responsible for copy the tools from the image to a bin volume. This ensures that the tools are available to the ‘config-manager’ sidecar.

ScriptConfig object specifies a ConfigMap that contains script files that should be mounted inside the pod. The scripts are mounted as volumes and can be referenced and executed by the dynamic reload.

"SIGABRT"

"SIGALRM"

"SIGBUS"

"SIGCHLD"

"SIGCONT"

"SIGFPE"

"SIGHUP"

"SIGILL"

"SIGINT"

"SIGIO"

"SIGKILL"

"SIGPIPE"

"SIGPROF"

"SIGPWR"

"SIGQUIT"

"SIGSEGV"

"SIGSTKFLT"

"SIGSTOP"

"SIGSYS"

"SIGTERM"

"SIGTRAP"

"SIGTSTP"

"SIGTTIN"

"SIGTTOU"

"SIGURG"

"SIGUSR1"

"SIGUSR2"

"SIGVTALRM"

"SIGWINCH"

"SIGXCPU"

"SIGXFSZ"

(Members of ScriptConfig are embedded into this type.)

Specifies the ConfigMap that contains the script to be executed for reload.

Determines whether parameter updates should be synchronized with the “config-manager”. Specifies the controller’s reload strategy:

• If set to ‘True’, the controller executes the reload action in synchronous mode, pausing execution until the reload completes.
• If set to ‘False’, the controller executes the reload action in asynchronous mode, updating the ConfigMap without waiting for the reload process to finish.

Specifies the name of the init container.

Indicates whether the tool image should be used as the container image for a sidecar. This is useful for large tool images, such as those for C++ tools, which may depend on numerous libraries (e.g., *.so files).

If enabled, the tool image is deployed as a sidecar container image.

Examples:

 toolsSetup::
   mountPoint: /kb_tools
   toolConfigs:
     - name: kb-tools
       asContainerImage: true
       image:  apecloud/oceanbase:4.2.0.0-100010032023083021

generated containers:

initContainers:
 - name: install-config-manager-tool
   image: apecloud/kubeblocks-tools:${version}
   command:
   - cp
   - /bin/config_render
   - /opt/tools
   volumemounts:
   - name: kb-tools
     mountpath: /opt/tools
containers:
 - name: config-manager
   image: apecloud/oceanbase:4.2.0.0-100010032023083021
   imagePullPolicy: IfNotPresent
	  command:
   - /opt/tools/reloader
   - --log-level
   - info
   - --operator-update-enable
   - --tcp
   - "9901"
   - --config
   - /opt/config-manager/config-manager.yaml
   volumemounts:
   - name: kb-tools
     mountpath: /opt/tools

Specifies the tool container image.

Specifies the command to be executed by the init container.

Specifies the directory path in the container where the tools-related files are to be copied. This field is typically used with an emptyDir volume to ensure a temporary, empty directory is provided at pod creation.

Specifies a list of settings of init containers that prepare tools for dynamic reload.

Specifies a valid Unix signal to be sent. For a comprehensive list of all Unix signals, see: ../../pkg/configuration/configmap/handler.go:allUnixSignals

Identifies the name of the process to which the Unix signal will be sent.