Skip to content
Snippets Groups Projects
Select Git revision
1 result Searching

gatsby-node.js

Blame
    • Paul Melnikow's avatar
      6560706d
      Finish Typescripterizing the frontend (#4026) · 6560706d
      Paul Melnikow authored
      * Typescripterize RequestMarkupButton
      
      * Typescripterize Customizer
      
      * Typescripterize MarkupModalContent (+ tweaks)
      
      * More TypeScript
      
      * More TS
      
      * Fix build
      
      * Remove prop-types dependency
      
      * More types
      
      * Update frontend/components/badge-examples.tsx
      
      * Update frontend/components/badge-examples.tsx
      
      * RequestMarkupButton: Fix weird formatting on click
      6560706d
      History
      Finish Typescripterizing the frontend (#4026)
      Paul Melnikow authored
      * Typescripterize RequestMarkupButton
      
      * Typescripterize Customizer
      
      * Typescripterize MarkupModalContent (+ tweaks)
      
      * More TypeScript
      
      * More TS
      
      * Fix build
      
      * Remove prop-types dependency
      
      * More types
      
      * Update frontend/components/badge-examples.tsx
      
      * Update frontend/components/badge-examples.tsx
      
      * RequestMarkupButton: Fix weird formatting on click
    operator_parameters.md 50.21 KiB

    Configuration parameters

    There are two mutually-exclusive methods to set the Postgres Operator configuration.

    • ConfigMaps-based, the legacy one
    • CRD-based configuration

    Variable names are underscore-separated words.

    ConfigMaps-based

    The configuration is supplied in a key-value configmap, defined by the CONFIG_MAP_NAME environment variable. Non-scalar values, i.e. lists or maps, are encoded in the value strings using the comma-based syntax for lists and coma-separated key:value syntax for maps. String values containing ':' should be enclosed in quotes. The configuration is flat, parameter group names below are not reflected in the configuration structure. There is an example

    For the configmap configuration, the default parameter values mentioned here are likely to be overwritten in your local operator installation via your local version of the operator configmap. In the case you use the operator CRD, all the CRD defaults are provided in the operator's default configuration manifest

    CRD-based configuration

    The configuration is stored in a custom YAML manifest. The manifest is an instance of the custom resource definition (CRD) called OperatorConfiguration. The operator registers this CRD during the start and uses it for configuration if the operator deployment manifest sets the POSTGRES_OPERATOR_CONFIGURATION_OBJECT env variable to a non-empty value. The variable should point to the postgresql-operator-configuration object in the operator's namespace.

    The CRD-based configuration is a regular YAML document; non-scalar keys are simply represented in the usual YAML way. There are no default values built-in in the operator, each parameter that is not supplied in the configuration receives an empty value. In order to create your own configuration just copy the default one and change it.

    To test the CRD-based configuration locally, use the following

      kubectl create -f manifests/operatorconfiguration.crd.yaml # registers the CRD
      kubectl create -f manifests/postgresql-operator-default-configuration.yaml
    
      kubectl create -f manifests/operator-service-account-rbac.yaml
      kubectl create -f manifests/postgres-operator.yaml # set the env var as mentioned above
    
      kubectl get operatorconfigurations postgresql-operator-default-configuration -o yaml

    The CRD-based configuration is more powerful than the one based on ConfigMaps and should be used unless there is a compatibility requirement to use an already existing configuration. Even in that case, it should be rather straightforward to convert the ConfigMap-based configuration into the CRD-based one and restart the operator. The ConfigMap-based configuration will be deprecated and subsequently removed in future releases.

    Note that for the CRD-based configuration groups of configuration options below correspond to the non-leaf keys in the target YAML (i.e. for the Kubernetes resources the key is kubernetes). The key is mentioned alongside the group description. The ConfigMap-based configuration is flat and does not allow non-leaf keys.

    Since in the CRD-based case the operator needs to create a CRD first, which is controlled by the resource_check_interval and resource_check_timeout parameters, those parameters have no effect and are replaced by the CRD_READY_WAIT_INTERVAL and CRD_READY_WAIT_TIMEOUT environment variables. They will be deprecated and removed in the future.

    General

    Those are top-level keys, containing both leaf keys and groups.

    • enable_crd_registration Instruct the operator to create/update the CRDs. If disabled the operator will rely on the CRDs being managed separately. The default is true.

    • enable_crd_validation deprecated: toggles if the operator will create or update CRDs with OpenAPI v3 schema validation The default is true. false will be ignored, since apiextensions.io/v1 requires a structural schema definition.

    • crd_categories The operator will register CRDs in the all category by default so that they will be returned by a kubectl get all call. You are free to change categories or leave them empty.

    • enable_lazy_spilo_upgrade Instruct operator to update only the statefulsets with new images (Spilo and InitContainers) without immediately doing the rolling update. The assumption is pods will be re-started later with new images, for example due to the node rotation. The default is false.

    • enable_pgversion_env_var With newer versions of Spilo, it is preferable to use PGVERSION pod environment variable instead of the setting postgresql.bin_dir in the SPILO_CONFIGURATION env variable. When this option is true, the operator sets PGVERSION and omits postgresql.bin_dir from SPILO_CONFIGURATION. When false, the postgresql.bin_dir is set. This setting takes precedence over PGVERSION; see PR 222 in Spilo. The default is true.

    • enable_spilo_wal_path_compat enables backwards compatible path between Spilo 12 and Spilo 13+ images. The default is false.

    • enable_team_id_clustername_prefix To lower the risk of name clashes between clusters of different teams you can turn on this flag and the operator will sync only clusters where the name starts with the teamId (from spec) plus -. Default is false.

    • etcd_host Etcd connection string for Patroni defined as host:port. Not required when Patroni native Kubernetes support is used. The default is empty (use Kubernetes-native DCS).

    • kubernetes_use_configmaps Select if setup uses endpoints (default), or configmaps to manage leader when DCS is kubernetes (not etcd or similar). In OpenShift it is not possible to use endpoints option, and configmaps is required. By default, kubernetes_use_configmaps: false, meaning endpoints will be used.

    • docker_image Spilo Docker image for Postgres instances. For production, don't rely on the default image, as it might be not the most up-to-date one. Instead, build your own Spilo image from the github repository.

    • sidecar_docker_images deprecated: use sidecars instead. A map of sidecar names to Docker images to run with Spilo. In case of the name conflict with the definition in the cluster manifest the cluster-specific one is preferred.

    • sidecars a list of sidecars to run with Spilo, for any cluster (i.e. globally defined sidecars). Each item in the list is of type Container. Globally defined sidecars can be overwritten by specifying a sidecar in the Postgres manifest with the same name. Note: This field is not part of the schema validation. If the container specification is invalid, then the operator fails to create the statefulset.

    • enable_shm_volume Instruct operator to start any new database pod without limitations on shm memory. If this option is enabled, to the target database pod will be mounted a new tmpfs volume to remove shm memory limitation (see e.g. the docker issue). This option is global for an operator object, and can be overwritten by enableShmVolume parameter from Postgres manifest. The default is true.

    • workers number of working routines the operator spawns to process requests to create/update/delete/sync clusters concurrently. The default is 8.

    • max_instances operator will cap the number of instances in any managed Postgres cluster up to the value of this parameter. When -1 is specified, no limits are applied. The default is -1.

    • min_instances operator will run at least the number of instances for any given Postgres cluster equal to the value of this parameter. Standby clusters can still run with numberOfInstances: 1 as this is the recommended setup. When -1 is specified for min_instances, no limits are applied. The default is -1.

    • ignore_instance_limits_annotation_key for some clusters it might be required to scale beyond the limits that can be configured with min_instances and max_instances options. You can define an annotation key that can be used as a toggle in cluster manifests to ignore globally configured instance limits. The default is empty.

    • resync_period period between consecutive sync requests. The default is 30m.

    • repair_period period between consecutive repair requests. The default is 5m.

    • set_memory_request_to_limit Set memory_request to memory_limit for all Postgres clusters (the default value is also increased but configured max_memory_request can not be bypassed). This prevents certain cases of memory overcommitment at the cost of overprovisioning memory and potential scheduling problems for containers with high memory limits due to the lack of memory on Kubernetes cluster nodes. This affects all containers created by the operator (Postgres, connection pooler, logical backup, scalyr sidecar, and other sidecars except sidecars defined in the operator configuration); to set resources for the operator's own container, change the operator deployment manually. The default is false.

    Postgres users

    Parameters describing Postgres users. In a CRD-configuration, they are grouped under the users key.