From 1b6ef0ccfbc438142c6a48aee13eed332d67b895 Mon Sep 17 00:00:00 2001 From: Gabriele Bartolini Date: Sat, 22 Apr 2023 10:02:13 +0200 Subject: [PATCH 1/2] chore: minor changes to existing features Signed-off-by: Gabriele Bartolini --- postgres/spec/feature_matrix.yaml | 32 ++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/postgres/spec/feature_matrix.yaml b/postgres/spec/feature_matrix.yaml index 8569a93..3d38669 100644 --- a/postgres/spec/feature_matrix.yaml +++ b/postgres/spec/feature_matrix.yaml @@ -12,7 +12,7 @@ categories: description: | Mechanism(s) provided to install the operator. vendor_compliance: | - Provide a succinct value or list of values of the mechanisms supported. + Provide a succinct value or list of values of the supported mechanisms. If any of the following names apply, use them, and add other mechanism names, as needed: * YAML @@ -24,9 +24,9 @@ categories: name: Management via CRDs type: boolean description: | - The operator can be managed via CRDs (Custom Resource Definition). + The operator manages CRDs (Custom Resource Definition). vendor_compliance: | - If true, provide a list of the names of the CRDs supported by the operator. Names should be direct links to their documentation. + If true, provide a list of the names of the CRDs managed by the operator. Names should be direct links to their documentation or API reference. main: true - id: offin name: Offline installation @@ -55,7 +55,7 @@ categories: type: string_array description: | Indicate the base image of the images used by the operator. (e.g: scratch, ubi, fedora, ubuntu, centos, alpine, etc.). - Provide the image name without tags (e.g. debian instead of debian:8.11) + Provide the image name without tags (e.g. debian instead of debian:8.11). - id: olmcl name: Operator Capability Level type: string @@ -64,7 +64,7 @@ categories: levels in regards to their lifecycle management capabilities for the application or workload they deliver. The capability models aims to provide guidance in terminology to express what features users can expect from an operator. vendor_compliance: | - Capability level must be set one of the following levels: + Capability level must be set to one of the following levels: 1. `Basic Install` 2. `Seamless Upgrades` @@ -85,7 +85,7 @@ categories: description: | Which major (and minor) versions does this version of the operator support. vendor_compliance: | - Provide a list of every major version supported followed by a list in parenthesis of the minor versions supported for that major version. + Provide a list of every supported major version followed by a list in parenthesis of the minor versions supported for that major version. E.g. '15 (15.1, 15.0), 14 (14.3, 14.2)'. All versions must be ordered by reverse chronological order. Other components versions that are used may be described in the comments (e.g: Patroni, WAL-G, PgBackRest, PgBouncer, etc.) main: true @@ -164,7 +164,7 @@ categories: name: Deployment automation type: boolean description: | - The operator provides capabilities to deploy production-ready clusters automatically based on a provided configuration. + The operator provides capabilities to automatically deploy production-ready clusters based on a provided configuration. No user initiated commands must be required. - id: pomte name: Pod management technology @@ -274,7 +274,7 @@ categories: type: boolean description: | The number of pods in the cluster can be set to 0. This implies that no pods (no compute) would be used, but storage is not removed. - Upon scaling up, the cluster should be brought back up without the need to restore a backup. + Upon scaling up, the cluster should be brought back up without the need to restore a backup. This feature may also be known as "hibernation". - id: tblsp name: Tablespaces type: boolean @@ -358,7 +358,7 @@ categories: type: boolean description: | The operator provides the facility that in the event of a node or pod failure where the Postgres primary is affected, - another Postgres pod (if it exists) will be promoted to primary. The operation must happen automatically without user intervention. + another Postgres instance (if available) will be promoted to primary. The operation must happen automatically without user intervention. main: true - id: techa name: HA Technology @@ -468,10 +468,10 @@ categories: name: Bring your own extension type: boolean description: | - The opertor provides mechanisms for users to add (or upload) third-party extensions not initially provided by the operator. + The operator provides mechanisms for users to add (or upload) third-party extensions not initially provided by the operator. vendor_compliance: | The operator must support providing some mechanism to include custom extensions additionally or independently of the extension distribution mechanism, - if a user build a local extension it could be uploaded or included on the postgres container with an automatic copy to all replicas related. + if a user builds a local extension, this could be uploaded or included on the postgres container with an automatic copy to all replicas related. - id: bkup name: Backups features: @@ -501,7 +501,7 @@ categories: name: Automated backup management type: boolean description: | - The operator provides mechanisms for performing backups automatically and providing lifecycle mechanisms (delete old backups according to a user-supplied policy). + The operator provides mechanisms for performing backups automatically and providing lifecycle mechanisms (delete old backups according to a user-supplied policy - often known as retention policies). vendor_compliance: | True response for the feature implies both automatic backups and lifecycle management. If only the former is provided, answer should be false but this capability should be mentioned in the comments field. @@ -593,11 +593,12 @@ categories: name: Metrics technology type: string_array description: | - If the operator supports extracting metrics from Postgres, how are they handled, which technology receives and process them? + If the operator supports extracting metrics from Postgres, define how they are handled, which technology receives and processes them. If any of the following technology names apply, use them, and add other names, as needed: * Prometheus + * OTEL * OpenTSDB * Nagios * Sensu @@ -627,7 +628,7 @@ categories: type: boolean description: | The operator provides a mechanism to expose all the logs of the managed Postgres instances to a centralized logging tool. - The logs must be decorated with extra metadata that includes the Pod name and namespace, the cluster name, the role of the Postgres instance (e.g. primary, replica, standby-leader, etc.) and the timestamp that will be available to be used to filter logs entries. + The logs must be decorated with extra metadata in order to provide semantic meaning, including the Pod name and namespace, the cluster name, the role of the Postgres instance (e.g. primary, replica, standby-leader, etc.) and the timestamp that will be available to be used to filter logs entries. There is no need to configure the tool in order to obtain required extra metadata from the logs. - id: explg name: Export logs @@ -693,6 +694,7 @@ categories: vendor_compliance: | The operator must provide proper information to the user as to the status and final result of the operation. The operator should provide ongoing status information, and perform the operation with the minimum downtime required. + Provide information about the update strategy (i.e. restart of the pods or rolling update followed by a switchover or a restart). main: true - id: amaup name: Automated major upgrades @@ -720,7 +722,7 @@ categories: type: boolean description: | If HA capabilities are provided, the operator also provides a mechanism for manual switchover. - The user may specify the configuration declaratively and the operator will perform the desired switchover automatically, updating the endpoints/services as required. + The user may specify the configuration declaratively and the operator will perform the desired switchover automatically, by demoting the current primary, promoting the a replica, and updating the endpoints/services as required. - id: sqlmi name: SQL Migrations type: boolean From 5042d6b99c14abc948f5843d0d2fc75c65d68256 Mon Sep 17 00:00:00 2001 From: Leonardo Cecchi Date: Sat, 22 Apr 2023 18:05:21 +0200 Subject: [PATCH 2/2] chore: run yaml2md --- postgres/spec/feature_matrix.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/postgres/spec/feature_matrix.md b/postgres/spec/feature_matrix.md index 8c966d7..1d3c099 100644 --- a/postgres/spec/feature_matrix.md +++ b/postgres/spec/feature_matrix.md @@ -2,18 +2,18 @@ ## General Characteristics – [genc](#genc) | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | |---|---|---|---|---|---| -| instm | Installation mechanism | string_array | Mechanism(s) provided to install the operator. | Provide a succinct value or list of values of the mechanisms supported.
If any of the following names apply, use them, and add other mechanism names, as needed:

* YAML
* Helm
* Kustomize
* Operator Bundle
| ✓ | -| mcrds | Management via CRDs | boolean | The operator can be managed via CRDs (Custom Resource Definition). | If true, provide a list of the names of the CRDs supported by the operator. Names should be direct links to their documentation.
| ✓ | +| instm | Installation mechanism | string_array | Mechanism(s) provided to install the operator. | Provide a succinct value or list of values of the supported mechanisms.
If any of the following names apply, use them, and add other mechanism names, as needed:

* YAML
* Helm
* Kustomize
* Operator Bundle
| ✓ | +| mcrds | Management via CRDs | boolean | The operator manages CRDs (Custom Resource Definition). | If true, provide a list of the names of the CRDs managed by the operator. Names should be direct links to their documentation or API reference.
| ✓ | | offin | Offline installation | boolean | Whether it is possible to install the operator on a (air-gapped) cluster without internet connection. | A link should be provided with documentation on how to install the operator on air-gapped environments.
| | | scpua | Supported CPU architectures | string_array | Support for the operator to run on nodes with specified CPU architectures. | Provide a list of CPU architectures that are supported between:

* amd64
* arm
* arm64
* ppc64le
* s390x

In case you support additional architectures, add their name(s) in a similar fashion.
| | -| coios | Container images OSes | string_array | Indicate the base image of the images used by the operator. (e.g: scratch, ubi, fedora, ubuntu, centos, alpine, etc.).
Provide the image name without tags (e.g. debian instead of debian:8.11) | | | -| olmcl | Operator Capability Level | string | [Operator Capability Levels](https://sdk.operatorframework.io/docs/overview/operator-capabilities/) indicates the operator maturity
levels in regards to their lifecycle management capabilities for the application or workload they deliver. The capability models
aims to provide guidance in terminology to express what features users can expect from an operator. | Capability level must be set one of the following levels:

1. `Basic Install`
2. `Seamless Upgrades`
3. `Full Lifecycle`
4. `Deep Insights`
5. `Auto Pilot`

A link should be provided with documentation on how the operator fulfil the declared capability level.

For a detailed description of each capability level refer to the Operator Framework documentation for
[Operator Capability Level](https://sdk.operatorframework.io/docs/overview/operator-capabilities/).
| | +| coios | Container images OSes | string_array | Indicate the base image of the images used by the operator. (e.g: scratch, ubi, fedora, ubuntu, centos, alpine, etc.).
Provide the image name without tags (e.g. debian instead of debian:8.11). | | | +| olmcl | Operator Capability Level | string | [Operator Capability Levels](https://sdk.operatorframework.io/docs/overview/operator-capabilities/) indicates the operator maturity
levels in regards to their lifecycle management capabilities for the application or workload they deliver. The capability models
aims to provide guidance in terminology to express what features users can expect from an operator. | Capability level must be set to one of the following levels:

1. `Basic Install`
2. `Seamless Upgrades`
3. `Full Lifecycle`
4. `Deep Insights`
5. `Auto Pilot`

A link should be provided with documentation on how the operator fulfil the declared capability level.

For a detailed description of each capability level refer to the Operator Framework documentation for
[Operator Capability Level](https://sdk.operatorframework.io/docs/overview/operator-capabilities/).
| | ## Versions – [vers](#vers) | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | |---|---|---|---|---|---| -| pgver | Supported PostgreSQL versions | string_array | Which major (and minor) versions does this version of the operator support. | Provide a list of every major version supported followed by a list in parenthesis of the minor versions supported for that major version.
E.g. '15 (15.1, 15.0), 14 (14.3, 14.2)'. All versions must be ordered by reverse chronological order.
Other components versions that are used may be described in the comments (e.g: Patroni, WAL-G, PgBackRest, PgBouncer, etc.)
| ✓ | +| pgver | Supported PostgreSQL versions | string_array | Which major (and minor) versions does this version of the operator support. | Provide a list of every supported major version followed by a list in parenthesis of the minor versions supported for that major version.
E.g. '15 (15.1, 15.0), 14 (14.3, 14.2)'. All versions must be ordered by reverse chronological order.
Other components versions that are used may be described in the comments (e.g: Patroni, WAL-G, PgBackRest, PgBouncer, etc.)
| ✓ | | k8ver | Supported Kubernetes versions | string_array | Which Kubernetes versions the operator can be installed into. | Provide a list of official Kubernetes minor versions numbers, ordered by reverse chronological order.
Use a range of versions, if possible, e.g. '1.26 - 1.23' or '1.22 - 1.19'.
| ✓ | | pgfor | PostgreSQL OSS forks | string_array | PostgreSQL forks are considered derived projects that started from PostgreSQL codebase and add different features while maintaining compatibility with PostgreSQL.
Some operators may provide support for some of such forks, alongside with the original PostgreSQL. | Leave empty if no version other than the original PostgreSQL is supported. Otherwise, provide a list of names and links to the PostgreSQL forks supported.
If non-OSS forks are supported, leave empty but add a link to them in the comments section.
| | @@ -32,7 +32,7 @@ ## PostgreSQL Clusters – [pgcl](#pgcl) | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | |---|---|---|---|---|---| -| depau | Deployment automation | boolean | The operator provides capabilities to deploy production-ready clusters automatically based on a provided configuration.
No user initiated commands must be required. | | | +| depau | Deployment automation | boolean | The operator provides capabilities to automatically deploy production-ready clusters based on a provided configuration.
No user initiated commands must be required. | | | | pomte | Pod management technology | string | Which Pod management technology is used to handle database's Pods. E.g. 'StatefulSet', 'Deployment', 'Custom', etc. | Provide the most succinct possible name of the technology. Use the Kubernetes resource type name (e.g. 'Deployment'), if applicable.
| ✓ | | pgcnf | PostgreSQL custom config | boolean | The operator allows the user to supply custom PostgreSQL configuration. | | | | conpl | Integrated connection pooling | boolean | The operator provides options to deploy a connection pool in front of the database, automatically deployed and configured. | The connection pool may be deployed in several ways, like a Deployment layer, a side car, etc.
All should be valid towards this feature as long as they are deployed automatically and offer an entrypoint for the user to the connection pooler.
| ✓ | @@ -48,7 +48,7 @@ | hugpa | Support for huge pages | boolean | The user may specify the request to use huge pages for Postgres (and/or potentially other sidecars).
Postgres must be able to be configured and start using huge pages. | | ✓ | | pgsrv | PostgreSQL exposed via Service | string | The operator creates by default or allows the user to request one or more Kubernetes Service(s) to be created to expose the PostgreSQL connections.
Expected capabilities should include a RW (read-write) or RO (read-only in case of cascading replication) connection to the primary instance; and, optionally, a RO (read-only) to load balance read-only replicas instances in the cluster. | The value must be one of:

* PrimaryAndReplicas: Primary and replicas services must be offered.
* PrimaryAndReplicasAndBalanced: Primary service, replicas services and a service that load balance RW/RO traffic transparently must be offered.
* Balanced: A single service that load balances RW/RO traffic transparently.
* Primary: Primary service must be offered.
| | | stosc | Automatic storage scaling | boolean | If the user's selected storage technology supports transparent scaling, the operator will take care of scaling the storage automatically
(either by setting some default thresholds or requiring explicit declarative configuration from the user). | | | -| scal0 | Scale down to zero | boolean | The number of pods in the cluster can be set to 0. This implies that no pods (no compute) would be used, but storage is not removed.
Upon scaling up, the cluster should be brought back up without the need to restore a backup. | | | +| scal0 | Scale down to zero | boolean | The number of pods in the cluster can be set to 0. This implies that no pods (no compute) would be used, but storage is not removed.
Upon scaling up, the cluster should be brought back up without the need to restore a backup. This feature may also be known as "hibernation". | | | | tblsp | Tablespaces | boolean | The user may specify one or more PostgreSQL tablespaces and their associated backing storage. | | | | cupgi | Custom Postgres images | boolean | The operator allows the user to specify custom (user-provided) Postgres container images, instead of using the operator's provided images. | The operator should specify if the custom image needs to follow some minimal patterns to be able to work, or if it can work
with any postgres container image provided.
| | | uside | User supplied sidecars | boolean | The user may specify custom sidecars (containers or init containers) to be created alongside the Postgres container (and, possibly, other operator sidecars).
User supplied sidecars must be able, by default or by configuration, to access the Postgres container filesystem and Unix Domain Sockets file. | | | @@ -64,7 +64,7 @@ ## HA & Replication – [harp](#harp) | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | |---|---|---|---|---|---| -| autfa | Automated failover | boolean | The operator provides the facility that in the event of a node or pod failure where the Postgres primary is affected,
another Postgres pod (if it exists) will be promoted to primary. The operation must happen automatically without user intervention. | | ✓ | +| autfa | Automated failover | boolean | The operator provides the facility that in the event of a node or pod failure where the Postgres primary is affected,
another Postgres instance (if available) will be promoted to primary. The operation must happen automatically without user intervention. | | ✓ | | techa | HA Technology | string | The technology (software name or technology principles) that support the high availability and automated failover capabilities of the operator. | Provide a succinct software or technology name. E.g.: Patroni, Stolon, Custom.
| ✓ | | asrep | Asynchronous replication | boolean | The operator allows to configure Postgres clusters using asynchronous streaming replication.
Asynchronous is the default streaming replication mode in Postgres. | | | | syrep | Synchronous replication | boolean | The operator allows to configure Postgres clusters using synchronous streaming replication.
The operator must manage the configuration details based on the user's preferences on which nodes behave synchronously. | | | @@ -83,7 +83,7 @@ | extme | Extensions distribution mechanism | string | This feature is set to describe how extensions are shipped in a containerized environment.
Typically they are part of the same Postgres container image, but they may also be distributed via other mechanisms. | Indicate 'built-in' if the extensions come included with the same Postgres container; or a succinct word or few words naming the distribution mechanism.
More details may be provided, if needed, via the links and comments fields.
| | | coext | Core/contrib extensions | integer | The number of core+contrib extensions provided by the operator for the latest Postgres version provided by the operator. | Submission must provide the total number of core+contrib extensions supported for the latest Postgres version provided by the operator.
It should also be provided, when available, a link with a detailed list of those extensions supported (via links field).
| ✓ | | thext | Third-party extensions | integer | The number of extensions not included in the Postgres core+contrib (i.e. created by third parties, outside of Postgres repository) for the latest Postgres version provided by the operator. | Submission must provide the total number of third-party extensions supported for the latest Postgres version provided by the operator.
A link with a detailed list of those extensions supported (via links field) should also be provided, if available.
| ✓ | -| byext | Bring your own extension | boolean | The opertor provides mechanisms for users to add (or upload) third-party extensions not initially provided by the operator. | The operator must support providing some mechanism to include custom extensions additionally or independently of the extension distribution mechanism,
if a user build a local extension it could be uploaded or included on the postgres container with an automatic copy to all replicas related.
| | +| byext | Bring your own extension | boolean | The operator provides mechanisms for users to add (or upload) third-party extensions not initially provided by the operator. | The operator must support providing some mechanism to include custom extensions additionally or independently of the extension distribution mechanism,
if a user builds a local extension, this could be uploaded or included on the postgres container with an automatic copy to all replicas related.
| | ## Backups – [bkup](#bkup) @@ -91,7 +91,7 @@ |---|---|---|---|---|---| | bktch | Backup Technology | string | What technology (pgbasebackup, PgBackRest, WAL-e/g, Barman, custom, etc) is used to support creation and restoration of backups. | Provide the most succinct possible name of the technology.
| ✓ | | bkdst | Backup destinations | string_array | Where backups can be stored (typically this may include object stores, PVs, etc). | If any of the following technology names apply, use them, and add other names, as needed:

* PersistentVolume
* NFS
* S3
* GCS
* Azure Blob
* Local file system
| | -| autbk | Automated backup management | boolean | The operator provides mechanisms for performing backups automatically and providing lifecycle mechanisms (delete old backups according to a user-supplied policy). | True response for the feature implies both automatic backups and lifecycle management.
If only the former is provided, answer should be false but this capability should be mentioned in the comments field.
| ✓ | +| autbk | Automated backup management | boolean | The operator provides mechanisms for performing backups automatically and providing lifecycle mechanisms (delete old backups according to a user-supplied policy - often known as retention policies). | True response for the feature implies both automatic backups and lifecycle management.
If only the former is provided, answer should be false but this capability should be mentioned in the comments field.
| ✓ | | encbk | Backups encryption | boolean | Backups can be performed with user-supplied encryption keys. | | | | ptrbk | Point In Time Recovery | boolean | The operator provides support for the user to specify a recovery point (in the past) to which a backup should be recovered to
(if unspecified, backup will be recovered in full). | True response implies that at least time-based recovery is supported.
If the operator also supports PITR by xid and label, clarify in the comments field.
| | | mulbk | Multiple backup configurations | boolean | The operator supports managing more than one backup configuration.
This is typically used to store backups on different object stores (for protection purposes) or to send them to different sites.
It may also include different lifecycle policies. | | | @@ -112,11 +112,11 @@ ## Observability – [o11y](#o11y) | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | |---|---|---|---|---|---| -| mtech | Metrics technology | string_array | If the operator supports extracting metrics from Postgres, how are they handled, which technology receives and process them?

If any of the following technology names apply, use them, and add other names, as needed:

* Prometheus
* OpenTSDB
* Nagios
* Sensu | If supported, provide in the comments information about whether the technology is a dependency, is built-in, external, etc.
Provide link(s) to the documentation for further information.
| ✓ | +| mtech | Metrics technology | string_array | If the operator supports extracting metrics from Postgres, define how they are handled, which technology receives and processes them.

If any of the following technology names apply, use them, and add other names, as needed:

* Prometheus
* OTEL
* OpenTSDB
* Nagios
* Sensu | If supported, provide in the comments information about whether the technology is a dependency, is built-in, external, etc.
Provide link(s) to the documentation for further information.
| ✓ | | expme | Export metrics | boolean | Regardless of how metrics are processed (e.g. as part of the operator),
this feature is implemented when the operator allows the user to configure sending metrics to external services, like a metrics SaaS. | | | | cudas | Custom dashboards | boolean | In order to display the captured Postgres metrics, the operator provides specialized Postgres dashboards for the users. | | | | cuale | Custom alerts | boolean | The operator provides bundled specific Postgres alerts to be triggered on the Postgres metrics processed.
E.g. there is an alert for transaction wraparound or for unused replication slots. | | | -| exdel | Exposed decorated logs | boolean | The operator provides a mechanism to expose all the logs of the managed Postgres instances to a centralized logging tool.
The logs must be decorated with extra metadata that includes the Pod name and namespace, the cluster name, the role of the Postgres instance (e.g. primary, replica, standby-leader, etc.) and the timestamp that will be available to be used to filter logs entries.
There is no need to configure the tool in order to obtain required extra metadata from the logs. | | | +| exdel | Exposed decorated logs | boolean | The operator provides a mechanism to expose all the logs of the managed Postgres instances to a centralized logging tool.
The logs must be decorated with extra metadata in order to provide semantic meaning, including the Pod name and namespace, the cluster name, the role of the Postgres instance (e.g. primary, replica, standby-leader, etc.) and the timestamp that will be available to be used to filter logs entries.
There is no need to configure the tool in order to obtain required extra metadata from the logs. | | | | explg | Export logs | boolean | The operator allows the user to configure an external sink for the Postgres logs (e.g. a SaaS service). | | | | oo11y | Operator Observability | boolean | The operator is itself a source of telemetry data, potentially including metrics, traces and logs, about its own performance. | | | @@ -135,11 +135,11 @@ ## Day 2 Operations – [day2](#day2) | **ID** | **NAME** | **TYPE** | **DESCRIPTION** | **VENDOR COMPLIANCE** | **MAIN CATEGORY** | |---|---|---|---|---|---| -| amiup | Automated minor upgrades | boolean | The operator can perform a minor version upgrade of a Postgres cluster automatically.
This operation can be managed by the user declaratively. | The operator must provide proper information to the user as to the status and final result of the operation.
The operator should provide ongoing status information, and perform the operation with the minimum downtime required.
| ✓ | +| amiup | Automated minor upgrades | boolean | The operator can perform a minor version upgrade of a Postgres cluster automatically.
This operation can be managed by the user declaratively. | The operator must provide proper information to the user as to the status and final result of the operation.
The operator should provide ongoing status information, and perform the operation with the minimum downtime required.
Provide information about the update strategy (i.e. restart of the pods or rolling update followed by a switchover or a restart).
| ✓ | | amaup | Automated major upgrades | boolean | The operator can perform a major version upgrade of a Postgres cluster automatically.
This operation can be managed by the user declaratively. | The operator must provide proper information to the user as to the status and final result of the operation.
The operator should provide ongoing status information, and perform the operation with the minimum downtime required.
| ✓ | | crest | Controlled cluster restart | boolean | Sometimes Postgres needs to be restarted (e.g. changing of a parameter that requires restart).
The operator provides means to perform this operation automatically and in a controlled manner (rolling restart) so that the cluster faces a minimal downtime only. | | | | ociup | Container images upgrade | boolean | Similarly to the controlled restart operation, the operator is capable of updating the running container images (which require a pod restart) automatically and with minimal cluster impact. | | | -| swtch | Switchover | boolean | If HA capabilities are provided, the operator also provides a mechanism for manual switchover.
The user may specify the configuration declaratively and the operator will perform the desired switchover automatically, updating the endpoints/services as required. | | | +| swtch | Switchover | boolean | If HA capabilities are provided, the operator also provides a mechanism for manual switchover.
The user may specify the configuration declaratively and the operator will perform the desired switchover automatically, by demoting the current primary, promoting the a replica, and updating the endpoints/services as required. | | | | sqlmi | SQL Migrations | boolean | The operator provides managed SQL migration capabilities.
The user may specify SQL scripts that contain migrations (DDL changes, etc) to be deployed to a given database, having the operator apply them automatically. | The operator must report back to the user detailed information about the results of the execution(s) of the script(s) provided by the user.
| | | oday2 | Other Day 2 Operations | string_array | The operator provides support for other managed Day 2 operations. | All the mentioned additional day 2 operations need to be possible via declarative configuration and the operator to fully execute them without further user intervention.
| |