ricardozanini commented on code in PR #717:
URL:
https://github.com/apache/incubator-kie-kogito-docs/pull/717#discussion_r2060485118
##########
serverlessworkflow/modules/ROOT/pages/cloud/operator/supporting-services.adoc:
##########
@@ -98,32 +98,44 @@ And thus, it's only recommended for development and testing
purposes.
The ephemeral deployment of a service requires no additional configurations
than the shown, <<supporting-services-configuration, here>>.
-[#postgresql-persistence-configuration]
-=== PostgreSQL persistence configuration
+[#database-migration-configuration]
+=== Database migration configuration
-The PostgreSQL persistence of a service is supported by a PostgreSQL server
instance that you must previously install on the cluster.
-The administration of that instance is totally independent of the
{operator_name} scope, and to connect a supporting service with it, you must
only configure the correct database connection parameters.
+The term database migration refers to either initializing a given Data Index
or Jobs Service database to the respective schema, or applying data or schema
updates as new versions are released.
+
+The database migration strategy must be configured individually for each
supporting service, by using the optional
`dataIndex.persistence.dbMigrationStrategy` and
`jobService.persistence.dbMigrationStrategy` fields respectively.
+
+You can use any of the following database migration strategies: `job`,
`service` and `none`. When not configured, the default value is `service`.
+
+[NOTE]
+====
+Currently, the database migration is only supported when you use the
PostgreSQL persistence configuration.
+====
+
+==== Job based database migration strategy
+
+When you configure the `job` based strategy, the {product_name} Operator
decouples the database migration by using a dedicated Kubernetes Job that
manages all the migration procedure.
Review Comment:
```suggestion
When you configure the `job` based strategy, the {product_name} Operator
decouples the database migration by using a dedicated Kubernetes Job that
manages the entire migration process.
```
##########
serverlessworkflow/modules/ROOT/pages/cloud/operator/supporting-services.adoc:
##########
@@ -98,32 +98,44 @@ And thus, it's only recommended for development and testing
purposes.
The ephemeral deployment of a service requires no additional configurations
than the shown, <<supporting-services-configuration, here>>.
-[#postgresql-persistence-configuration]
-=== PostgreSQL persistence configuration
+[#database-migration-configuration]
+=== Database migration configuration
-The PostgreSQL persistence of a service is supported by a PostgreSQL server
instance that you must previously install on the cluster.
-The administration of that instance is totally independent of the
{operator_name} scope, and to connect a supporting service with it, you must
only configure the correct database connection parameters.
+The term database migration refers to either initializing a given Data Index
or Jobs Service database to the respective schema, or applying data or schema
updates as new versions are released.
+
+The database migration strategy must be configured individually for each
supporting service, by using the optional
`dataIndex.persistence.dbMigrationStrategy` and
`jobService.persistence.dbMigrationStrategy` fields respectively.
+
+You can use any of the following database migration strategies: `job`,
`service` and `none`. When not configured, the default value is `service`.
+
+[NOTE]
+====
+Currently, the database migration is only supported when you use the
PostgreSQL persistence configuration.
Review Comment:
```suggestion
Currently, database migration is only supported when using the PostgreSQL
persistence configuration.
```
##########
serverlessworkflow/modules/ROOT/pages/cloud/operator/supporting-services.adoc:
##########
@@ -98,32 +98,44 @@ And thus, it's only recommended for development and testing
purposes.
The ephemeral deployment of a service requires no additional configurations
than the shown, <<supporting-services-configuration, here>>.
-[#postgresql-persistence-configuration]
-=== PostgreSQL persistence configuration
+[#database-migration-configuration]
+=== Database migration configuration
-The PostgreSQL persistence of a service is supported by a PostgreSQL server
instance that you must previously install on the cluster.
-The administration of that instance is totally independent of the
{operator_name} scope, and to connect a supporting service with it, you must
only configure the correct database connection parameters.
+The term database migration refers to either initializing a given Data Index
or Jobs Service database to the respective schema, or applying data or schema
updates as new versions are released.
+
+The database migration strategy must be configured individually for each
supporting service, by using the optional
`dataIndex.persistence.dbMigrationStrategy` and
`jobService.persistence.dbMigrationStrategy` fields respectively.
+
+You can use any of the following database migration strategies: `job`,
`service` and `none`. When not configured, the default value is `service`.
+
+[NOTE]
+====
+Currently, the database migration is only supported when you use the
PostgreSQL persistence configuration.
+====
+
+==== Job based database migration strategy
+
+When you configure the `job` based strategy, the {product_name} Operator
decouples the database migration by using a dedicated Kubernetes Job that
manages all the migration procedure.
-==== {product_name} Operator Database Migrator capabilities
-The {product_name} Operator offers out of the box database migration features,
which help in configuring the databases for use by Data Index and/or Jobs
Service.
+That Job, executes prior to the supporting services deployment, and thus,
ensures that a given service is started only if the corresponding migration was
successful.
Review Comment:
```suggestion
That Job executes before the supporting services deployment, and thus,
ensures that a given service is started only if the corresponding migration was
successful.
```
##########
serverlessworkflow/modules/ROOT/pages/cloud/operator/supporting-services.adoc:
##########
@@ -98,32 +98,44 @@ And thus, it's only recommended for development and testing
purposes.
The ephemeral deployment of a service requires no additional configurations
than the shown, <<supporting-services-configuration, here>>.
-[#postgresql-persistence-configuration]
-=== PostgreSQL persistence configuration
+[#database-migration-configuration]
+=== Database migration configuration
-The PostgreSQL persistence of a service is supported by a PostgreSQL server
instance that you must previously install on the cluster.
-The administration of that instance is totally independent of the
{operator_name} scope, and to connect a supporting service with it, you must
only configure the correct database connection parameters.
+The term database migration refers to either initializing a given Data Index
or Jobs Service database to the respective schema, or applying data or schema
updates as new versions are released.
+
+The database migration strategy must be configured individually for each
supporting service, by using the optional
`dataIndex.persistence.dbMigrationStrategy` and
`jobService.persistence.dbMigrationStrategy` fields respectively.
+
+You can use any of the following database migration strategies: `job`,
`service` and `none`. When not configured, the default value is `service`.
+
+[NOTE]
+====
+Currently, the database migration is only supported when you use the
PostgreSQL persistence configuration.
+====
+
+==== Job based database migration strategy
+
+When you configure the `job` based strategy, the {product_name} Operator
decouples the database migration by using a dedicated Kubernetes Job that
manages all the migration procedure.
-==== {product_name} Operator Database Migrator capabilities
-The {product_name} Operator offers out of the box database migration features,
which help in configuring the databases for use by Data Index and/or Jobs
Service.
+That Job, executes prior to the supporting services deployment, and thus,
ensures that a given service is started only if the corresponding migration was
successful.
-The term database migration refers to either initializing a given Data Index
or Jobs Service database to the schema needed by them or applying data or
schema updates as new versions are released.
+You would typically use this strategy in production environments.
-{product_name} Operator offers jobs based database migration capabilities
along with two other modes: service based database migration and none.
+==== Service based database migration strategy
-The {product_name} Operator offered database migration modes are described as
follows.
+When you configure the `service` based strategy, the database migration is
managed by each of the supporting services, and is executed as part of the
service is starting sequence.
+In worst scenarios, a service could start with failures.
Review Comment:
```suggestion
When you configure the `service` based strategy, the database migration is
managed by each supporting service and is executed as part of the service's
startup sequence.
In worst-case scenarios, a service could start with failures.
```
##########
serverlessworkflow/modules/ROOT/pages/cloud/operator/supporting-services.adoc:
##########
@@ -184,97 +196,65 @@ To create the secrets for the example above you can use a
command like this:
kubectl create secret generic postgres-secrets-example
--from-literal=POSTGRESQL_USER=<user>
--from-literal=POSTGRESQL_PASSWORD=<password> -n postgres-example-namespace
----
-[#common-persistence-scenarios]
-=== Persistence examples with most common scenarios
-==== Specify database information at persistence level instead of service level
-You will use SonataFlowPlatform CR's `.spec.persistence.postgresql` to specify
the database to be used by the Data Index and Jobs Service. Then, specify the
database migration mode to use under
`.spec.services.dataIndex.persistence.dbMigrationStrategy` or
`.spec.services.jobService.persistence.dbMigrationStrategy` with a value such
as job, service, or none.
-In this mode the Data Index and Jobs Service will make use of one common
database.
+[#common-persistence-configuration]
+=== Platform-scoped PostgreSQL persistence configuration
+
+To configure a common PostgreSQL service and database for the supporting
services, you must use the field `spec.persistence.postgresql` in the
`SonataFlowPlatform` CR.
+
+This information signals the {operator_name} to automatically configure the
supporting services to connect to that database.
+
+Additionally, workflows deployed in that namespace, with the `preview` or
`gitops` profile, that don’t provide a custom persistence configuration, will
connect to that database too,
xref:cloud/operator/using-persistence.adoc#configuring-persistence-using-the-sonataflowplatform-cr[see].
+
+And, similarly to the workflow's persistence, the following rules apply:
+
+* If a supporting service has a configured persistence, for example, the field
`services.dataIndex.persistence.postgresql` is configured. That configuration
will apply.
+
+* If a supporting service has no configured persistence, for example, the
field `services.dataIndex.persistence.postgresql` is not set at all, the
persistence configuration will be taken from the current platform.
Review Comment:
```suggestion
To configure a common PostgreSQL service and database for the supporting
services, you must use the field `spec.persistence.postgresql` in the
`SonataFlowPlatform` CR.
This information signals the {operator_name} to configure the supporting
services to connect to that database.
Additionally, workflows deployed in that namespace, with the `preview` or
`gitops` profile, that don’t provide a custom persistence configuration, will
connect to that database too,
xref:cloud/operator/using-persistence.adoc#configuring-persistence-using-the-sonataflowplatform-cr[see].
And, similarly to the workflow's persistence, the following rules apply:
* If a supporting service has a configured persistence, for example, the
field `services.dataIndex.persistence.postgresql` is configured. That
configuration will apply.
* If a supporting service has no configured persistence, for example, if the
`services.dataIndex.persistence.postgresql` field is not set, the persistence
configuration will be taken from the current platform.
```
##########
serverlessworkflow/modules/ROOT/pages/cloud/operator/supporting-services.adoc:
##########
@@ -98,32 +98,44 @@ And thus, it's only recommended for development and testing
purposes.
The ephemeral deployment of a service requires no additional configurations
than the shown, <<supporting-services-configuration, here>>.
-[#postgresql-persistence-configuration]
-=== PostgreSQL persistence configuration
+[#database-migration-configuration]
+=== Database migration configuration
-The PostgreSQL persistence of a service is supported by a PostgreSQL server
instance that you must previously install on the cluster.
-The administration of that instance is totally independent of the
{operator_name} scope, and to connect a supporting service with it, you must
only configure the correct database connection parameters.
+The term database migration refers to either initializing a given Data Index
or Jobs Service database to the respective schema, or applying data or schema
updates as new versions are released.
+
+The database migration strategy must be configured individually for each
supporting service, by using the optional
`dataIndex.persistence.dbMigrationStrategy` and
`jobService.persistence.dbMigrationStrategy` fields respectively.
+
+You can use any of the following database migration strategies: `job`,
`service` and `none`. When not configured, the default value is `service`.
Review Comment:
```suggestion
The term database migration refers to either initializing a given Data Index
or Jobs Service database to the respective schema, or applying data or schema
updates as new versions are released.
The database migration strategy must be configured individually for each
supporting service, by using the optional
`dataIndex.persistence.dbMigrationStrategy` and
`jobService.persistence.dbMigrationStrategy` fields respectively.
You can use any of the following database migration strategies: `job`,
`service`, and `none`. When not configured, the default value is `service`.
```
##########
serverlessworkflow/modules/ROOT/pages/cloud/operator/supporting-services.adoc:
##########
@@ -98,32 +98,44 @@ And thus, it's only recommended for development and testing
purposes.
The ephemeral deployment of a service requires no additional configurations
than the shown, <<supporting-services-configuration, here>>.
-[#postgresql-persistence-configuration]
-=== PostgreSQL persistence configuration
+[#database-migration-configuration]
+=== Database migration configuration
-The PostgreSQL persistence of a service is supported by a PostgreSQL server
instance that you must previously install on the cluster.
-The administration of that instance is totally independent of the
{operator_name} scope, and to connect a supporting service with it, you must
only configure the correct database connection parameters.
+The term database migration refers to either initializing a given Data Index
or Jobs Service database to the respective schema, or applying data or schema
updates as new versions are released.
+
+The database migration strategy must be configured individually for each
supporting service, by using the optional
`dataIndex.persistence.dbMigrationStrategy` and
`jobService.persistence.dbMigrationStrategy` fields respectively.
+
+You can use any of the following database migration strategies: `job`,
`service` and `none`. When not configured, the default value is `service`.
+
+[NOTE]
+====
+Currently, the database migration is only supported when you use the
PostgreSQL persistence configuration.
+====
+
+==== Job based database migration strategy
+
+When you configure the `job` based strategy, the {product_name} Operator
decouples the database migration by using a dedicated Kubernetes Job that
manages all the migration procedure.
-==== {product_name} Operator Database Migrator capabilities
-The {product_name} Operator offers out of the box database migration features,
which help in configuring the databases for use by Data Index and/or Jobs
Service.
+That Job, executes prior to the supporting services deployment, and thus,
ensures that a given service is started only if the corresponding migration was
successful.
-The term database migration refers to either initializing a given Data Index
or Jobs Service database to the schema needed by them or applying data or
schema updates as new versions are released.
+You would typically use this strategy in production environments.
-{product_name} Operator offers jobs based database migration capabilities
along with two other modes: service based database migration and none.
+==== Service based database migration strategy
-The {product_name} Operator offered database migration modes are described as
follows.
+When you configure the `service` based strategy, the database migration is
managed by each of the supporting services, and is executed as part of the
service is starting sequence.
+In worst scenarios, a service could start with failures.
-.Jobs based database migration
-In this mode, the {product_name} Operator creates a Kubernetes Job and uses
the database migrator component to migrate configured databases. You would
typically use this mode when running in non-development scenarios such as
Production environments, where there could be an existing database for use by
Data Index and/or Jobs Service.
+==== None migration strategy
-.Service based database migration
-In this mode, the {product_name} Operator does not create a Kubernetes Job and
hence does not use the database migrator component to migrate configured
databases. In this mode, thus the Data Index or Jobs Service are responsible to
migrate the configured databases. You would typically use this mode when
running in development scenarios such as local environments, where you are
testing scenarios with clean state everytime you deploy and run.
+When you configure the `none` strategy, no Operator nor service migration
attempt is executed.
-.None mode
-In this mode, the {product_name} Operator makes no migration attempt.
+You would typically use this strategy in environments where all the database
migrations are executed by a database administrator.
Review Comment:
```suggestion
You would typically use this strategy in environments where a database
administrator executes all the database migrations.
```
##########
serverlessworkflow/modules/ROOT/pages/cloud/operator/supporting-services.adoc:
##########
@@ -98,32 +98,44 @@ And thus, it's only recommended for development and testing
purposes.
The ephemeral deployment of a service requires no additional configurations
than the shown, <<supporting-services-configuration, here>>.
-[#postgresql-persistence-configuration]
-=== PostgreSQL persistence configuration
+[#database-migration-configuration]
+=== Database migration configuration
-The PostgreSQL persistence of a service is supported by a PostgreSQL server
instance that you must previously install on the cluster.
-The administration of that instance is totally independent of the
{operator_name} scope, and to connect a supporting service with it, you must
only configure the correct database connection parameters.
+The term database migration refers to either initializing a given Data Index
or Jobs Service database to the respective schema, or applying data or schema
updates as new versions are released.
+
+The database migration strategy must be configured individually for each
supporting service, by using the optional
`dataIndex.persistence.dbMigrationStrategy` and
`jobService.persistence.dbMigrationStrategy` fields respectively.
+
+You can use any of the following database migration strategies: `job`,
`service` and `none`. When not configured, the default value is `service`.
+
+[NOTE]
+====
+Currently, the database migration is only supported when you use the
PostgreSQL persistence configuration.
+====
+
+==== Job based database migration strategy
+
+When you configure the `job` based strategy, the {product_name} Operator
decouples the database migration by using a dedicated Kubernetes Job that
manages all the migration procedure.
-==== {product_name} Operator Database Migrator capabilities
-The {product_name} Operator offers out of the box database migration features,
which help in configuring the databases for use by Data Index and/or Jobs
Service.
+That Job, executes prior to the supporting services deployment, and thus,
ensures that a given service is started only if the corresponding migration was
successful.
-The term database migration refers to either initializing a given Data Index
or Jobs Service database to the schema needed by them or applying data or
schema updates as new versions are released.
+You would typically use this strategy in production environments.
-{product_name} Operator offers jobs based database migration capabilities
along with two other modes: service based database migration and none.
+==== Service based database migration strategy
-The {product_name} Operator offered database migration modes are described as
follows.
+When you configure the `service` based strategy, the database migration is
managed by each of the supporting services, and is executed as part of the
service is starting sequence.
+In worst scenarios, a service could start with failures.
-.Jobs based database migration
-In this mode, the {product_name} Operator creates a Kubernetes Job and uses
the database migrator component to migrate configured databases. You would
typically use this mode when running in non-development scenarios such as
Production environments, where there could be an existing database for use by
Data Index and/or Jobs Service.
+==== None migration strategy
-.Service based database migration
-In this mode, the {product_name} Operator does not create a Kubernetes Job and
hence does not use the database migrator component to migrate configured
databases. In this mode, thus the Data Index or Jobs Service are responsible to
migrate the configured databases. You would typically use this mode when
running in development scenarios such as local environments, where you are
testing scenarios with clean state everytime you deploy and run.
+When you configure the `none` strategy, no Operator nor service migration
attempt is executed.
-.None mode
-In this mode, the {product_name} Operator makes no migration attempt.
+You would typically use this strategy in environments where all the database
migrations are executed by a database administrator.
+[#postgresql-persistence-configuration]
+=== PostgreSQL persistence configuration
-=== Overview of PostgreSQL persistence configuration
+The PostgreSQL persistence of a service is supported by a PostgreSQL server
instance that you must previously install on the cluster.
+The administration of that instance is totally independent of the
{operator_name} scope, and to connect a supporting service with it, you must
only configure the correct database connection parameters.
Review Comment:
```suggestion
The PostgreSQL persistence of a service is supported by a PostgreSQL server
instance that you must have previously installed on the cluster.
The administration of that instance is totally independent of the
{operator_name} scope, and to connect a supporting service with it, you must
only configure the correct database connection parameters.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
