diff --git a/docs/components/modeler/bpmn/business-rule-tasks/business-rule-tasks.md b/docs/components/modeler/bpmn/business-rule-tasks/business-rule-tasks.md index 3fbf3e0bdc..6e3114634e 100644 --- a/docs/components/modeler/bpmn/business-rule-tasks/business-rule-tasks.md +++ b/docs/components/modeler/bpmn/business-rule-tasks/business-rule-tasks.md @@ -44,9 +44,9 @@ a `string`. The `bindingType` attribute determines which version of the called decision is evaluated: -- `latest`: the latest deployed version at the moment the business rule task is activated. -- `deployment`: the version that was deployed together with the currently running version of the process. -- `versionTag`: the latest deployed version that is annotated with the version tag specified in the `versionTag` attribute. +- `latest`: The latest deployed version at the moment the business rule task is activated. +- `deployment`: The version that was deployed together with the currently running version of the process. +- `versionTag`: The latest deployed version that is annotated with the version tag specified in the `versionTag` attribute. To learn more about choosing binding types, see [Choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). diff --git a/docs/components/modeler/bpmn/call-activities/call-activities.md b/docs/components/modeler/bpmn/call-activities/call-activities.md index e316fdcce1..fca0089293 100644 --- a/docs/components/modeler/bpmn/call-activities/call-activities.md +++ b/docs/components/modeler/bpmn/call-activities/call-activities.md @@ -20,9 +20,9 @@ Usually, the `processId` is defined as a [static value](/components/concepts/exp The `bindingType` attribute determines which version of the called process is instantiated: -- `latest`: the latest deployed version at the moment the call activity is activated. -- `deployment`: the version that was deployed together with the currently running version of the calling process. -- `versionTag`: the latest deployed version that is annotated with the version tag specified in the `versionTag` attribute. +- `latest`: The latest deployed version at the moment the call activity is activated. +- `deployment`: The version that was deployed together with the currently running version of the calling process. +- `versionTag`: The latest deployed version that is annotated with the version tag specified in the `versionTag` attribute. To learn more about choosing binding types, see [Choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). diff --git a/docs/components/modeler/bpmn/user-tasks/user-tasks.md b/docs/components/modeler/bpmn/user-tasks/user-tasks.md index 10013ce4d3..e00ed2cf75 100644 --- a/docs/components/modeler/bpmn/user-tasks/user-tasks.md +++ b/docs/components/modeler/bpmn/user-tasks/user-tasks.md @@ -121,9 +121,9 @@ Depending on your use case, two different types of form references can be used: The `bindingType` attribute determines which version of the linked form is used: - - `latest`: the latest deployed version at the moment the user task is activated. - - `deployment`: the version that was deployed together with the currently running version of the process. - - `versionTag`: the latest deployed version that is annotated with the version tag specified in the `versionTag` attribute. + - `latest`: The latest deployed version at the moment the user task is activated. + - `deployment`: The version that was deployed together with the currently running version of the process. + - `versionTag`: The latest deployed version that is annotated with the version tag specified in the `versionTag` attribute. To learn more about choosing binding types, see [Choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). diff --git a/docs/components/modeler/web-modeler/advanced-modeling/business-rule-task-linking.md b/docs/components/modeler/web-modeler/advanced-modeling/business-rule-task-linking.md index eb4b848769..b6d1979352 100644 --- a/docs/components/modeler/web-modeler/advanced-modeling/business-rule-task-linking.md +++ b/docs/components/modeler/web-modeler/advanced-modeling/business-rule-task-linking.md @@ -26,8 +26,8 @@ For business rule tasks that are already linked, clicking on the link icon opens You can also enter the Decision ID directly in the **Called decision** section in the properties panel after selecting **DMN decision** for the **Implementation**. -- **Binding**: You can also select a different Binding for the called decision. See [Choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). -- **Version tag**: If you select **version tag** for the Binding, you must enter the actual version tag to use. +- **Binding**: You can also select a different binding for the called decision. See [choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). +- **Version tag**: If you select **version tag** for the binding, you must enter the actual version tag to use.

called decision section in properties panel

diff --git a/docs/components/modeler/web-modeler/advanced-modeling/call-activity-linking.md b/docs/components/modeler/web-modeler/advanced-modeling/call-activity-linking.md index 1055533019..0b1ba196d4 100644 --- a/docs/components/modeler/web-modeler/advanced-modeling/call-activity-linking.md +++ b/docs/components/modeler/web-modeler/advanced-modeling/call-activity-linking.md @@ -24,8 +24,8 @@ For call activities that are already linked, clicking on the link button opens a You can also enter the process ID directly in the **Called element** section in the properties panel. -- **Binding**: You can also select a different Binding for the called decision. See [Choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). -- **Version tag**: If you select **version tag** for the Binding, you must enter the actual version tag to use. +- **Binding**: You can also select a different binding for the called decision. See [choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). +- **Version tag**: If you select **version tag** for the binding, you must enter the actual version tag to use.

called element section in properties panel

diff --git a/docs/components/modeler/web-modeler/advanced-modeling/form-linking.md b/docs/components/modeler/web-modeler/advanced-modeling/form-linking.md index 3fea0b463b..c7cf43464f 100644 --- a/docs/components/modeler/web-modeler/advanced-modeling/form-linking.md +++ b/docs/components/modeler/web-modeler/advanced-modeling/form-linking.md @@ -38,10 +38,10 @@ Using the properties panel, you can connect a form to a user task/start event vi ### Camunda Form (linked) -Choosing **Camunda Form (linked)** as the type and entering the form ID directly, produces the same result as [using the link button on the modeling canvas](#using-the-link-button). +Choosing **Camunda Form (linked)** as the type and entering the form ID directly produces the same result as [using the link button on the modeling canvas](#using-the-link-button). -- **Binding**: You can also select a different Binding for the linked form. See [Choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). -- **Version tag**: If you select **version tag** for the Binding, you must enter the actual version tag to use. +- **Binding**: You can also select a different binding for the called decision. See [choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). +- **Version tag**: If you select **version tag** for the binding, you must enter the actual version tag to use.

form section in properties panel

diff --git a/docs/reference/announcements.md b/docs/reference/announcements.md index 592f81ff98..8bc11c1cc2 100644 --- a/docs/reference/announcements.md +++ b/docs/reference/announcements.md @@ -52,7 +52,7 @@ The Zeebe Java client will not be developed further and will only receive bug fi ### Deprecation: Zeebe Go client & zbctl -The Zeebe Go Client and zbctl will be officially deprecated with the 8.6 release as part of our efforts to streamline the Camunda 8 API experience. This client and CLI utility will not get released starting with Camunda 8.6, will no longer receive new features, and will be transitioned to a community-maintained status. +The Zeebe Go Client and zbctl will be officially deprecated with the 8.6 release as part of our efforts to streamline the Camunda 8 API experience. This client and CLI utility will not be released with Camunda 8.6, will no longer receive new features, and will be transitioned to a community-maintained status. ### Camunda 8 SaaS - Required cluster update diff --git a/docs/reference/dependencies.md b/docs/reference/dependencies.md index 7ac30f1bd2..3a459ef782 100644 --- a/docs/reference/dependencies.md +++ b/docs/reference/dependencies.md @@ -2066,7 +2066,7 @@ All of these libraries are required for core functionality. - **Dependencies:** You can find an up-to-date list of third party libraries used and their license terms in the [THIRD_PARTY_NOTICES](https://github.com/camunda/camunda-modeler/blob/master/THIRD_PARTY_NOTICES), located in the root of the source code repository. This file is also shipped with the application distribution as `THIRD_PARTY_NOTICES.camunda-modeler.txt`. -- **Source code:** You can access the source code of the Desktop Modeler on [github.com/camunda/camunda-modeler](https://github.com/camunda/camunda-modeler) +- **Source code:** Access the source code for Desktop Modeler at [github.com/camunda/camunda-modeler](https://github.com/camunda/camunda-modeler). @@ -3082,8 +3082,8 @@ All of these libraries are required for core functionality. -- **Dependencies:** You can find a SBOM CycloneDX file with an up-to-date list of third party libraries used and their licenses in the [release assets](https://github.com/camunda/connectors/releases) of each Connectors release. -- **Source code:** You can access the source code of Connectors on [github.com/camunda/connectors](https://github.com/camunda/connectors) +- **Dependencies:** Find a SBOM CycloneDX file with an up-to-date list of third party libraries used and their licenses in the [release assets](https://github.com/camunda/connectors/releases) of each Connectors release. +- **Source code:** Access the source code for Connectors at [github.com/camunda/connectors](https://github.com/camunda/connectors). diff --git a/docs/self-managed/concepts/multi-region/dual-region.md b/docs/self-managed/concepts/multi-region/dual-region.md index 7e1d9097ae..807d1cab09 100644 --- a/docs/self-managed/concepts/multi-region/dual-region.md +++ b/docs/self-managed/concepts/multi-region/dual-region.md @@ -86,16 +86,16 @@ In the event of a total active region loss, the following data will be lost: - Task assignments -## Requirements and Limitations +## Requirements and limitations -### Installation Environment +### Installation environment -#### Kubernetes Setup +#### Kubernetes setup - Two Kubernetes clusters are required for the Helm chart installation. - OpenSearch (both managed and self-managed) is not supported in this dual-region setup. -#### Network Requirements +#### Network requirements - Kubernetes clusters, services, and pods must not have overlapping CIDRs. Each cluster must use distinct CIDRs that do not conflict or overlap with those of any other cluster; otherwise, you will encounter routing issues. - The regions (for example, two Kubernetes clusters) must be able to connect to each other (for example, via VPC peering). See [example implementation](/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md) for AWS EKS. @@ -108,16 +108,16 @@ In the event of a total active region loss, the following data will be lost: - **26500** for communication to the Zeebe Gateway from clients/workers. - **26501** and **26502** for communication between Zeebe brokers and Zeebe Gateway. -### Zeebe Cluster Configuration +### Zeebe cluster configuration -Only a combination for Zeebe broker counts and replication factors is supported: +Only a combination for Zeebe broker counts and replication factors are supported: - `clusterSize` must be a multiple of **2** and at least **4** to evenly distribute brokers across the two regions. - `replicationFactor` must be **4** to ensure even partition distribution across regions. - `partitionCount` is unrestricted but should be chosen based on workload requirements. See [understanding sizing and scalability behavior](../../../components/best-practices/architecture/sizing-your-environment.md#understanding-sizing-and-scalability-behavior). - For more details on partition distribution, see [documentation on partitions](../../../components/zeebe/technical-concepts/partitions.md). -### Regional Failure Management +### Regional failure management Customers are responsible for detecting regional failures and executing the [operational procedure](./../../operational-guides/multi-region/dual-region-ops.md). @@ -125,13 +125,13 @@ Customers are responsible for detecting regional failures and executing the [ope | **Aspect** | **Details** | | :----------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Installation methods |

| -| Camunda Platform Configuration |

The overall Camunda platform is **active-passive**, although some key components are active-active.

| -| Identity Support | Identity is not supported, multi-Tenancy and Role-Based Access Control (RBAC) does not work. | -| Optimize Support | Not supported (requires Identity). | -| Connectors Deployment | Connectors can be deployed in a dual-region setup, but attention to [idempotency](../../../components/connectors/use-connectors/inbound.md#creating-the-connector-event) is required to avoid event duplication. In a dual-region setup, you'll have two connector deployments and using message idempotency is of importance to not duplicate events. | -| Zeebe Cluster Scaling | Not supported. | -| Web-Modeler | Is a standalone component not covered in this guide. Modeling applications can operate independently outside of the automation clusters. | +| Installation methods |

| +| Camunda Platform configuration |

The overall Camunda platform is **active-passive**, although some key components are active-active.

| +| Identity support | Identity is not supported, multi-tenancy and Role-Based Access Control (RBAC) does not work. | +| Optimize support | Not supported (requires Identity). | +| Connectors deployment | Connectors can be deployed in a dual-region setup, but attention to [idempotency](../../../components/connectors/use-connectors/inbound.md#creating-the-connector-event) is required to avoid event duplication. In a dual-region setup, you'll have two Connector deployments and using message idempotency is important to not duplicate events. | +| Zeebe cluster scaling | Not supported. | +| Web Modeler | A standalone component not covered in this guide. Modeling applications can operate independently outside of the automation clusters. | ### Platform considerations @@ -160,53 +160,49 @@ The [operational procedure](./../../operational-guides/multi-region/dual-region- The loss of the active region results in the following: -- **Loss of Data**: Data previously available in Operate and Tasklist is no longer accessible. -- **Service Disruption**: Traffic routed to the active region can no longer be served. -- **Workflow Engine Failure**: The workflow engine stops processing due to quorum loss. +- **Loss of data**: Data previously available in Operate and Tasklist is no longer accessible. +- **Service disruption**: Traffic routed to the active region can no longer be served. +- **Workflow engine failure**: The workflow engine stops processing due to quorum loss. #### Steps to take in case of active region loss -1. **Temporary Recovery:** Follow the [operational procedure for temporary recovery](./../../operational-guides/multi-region/dual-region-ops.md#failover) to restore functionality and unblock the workflow engine. -2. **Traffic Rerouting:** Reroute traffic to the passive region, which will now become the new active region. -3. **Data and Task Management:** Due to the loss of data in Operate and Tasklist: +1. **Temporary recovery:** Follow the [operational procedure for temporary recovery](./../../operational-guides/multi-region/dual-region-ops.md#failover) to restore functionality and unblock the workflow engine. +2. **Traffic rerouting:** Reroute traffic to the passive region, which will now become the new active region. +3. **Data and task management:** Due to the loss of data in Operate and Tasklist. 1. Reassign any uncompleted tasks in Tasklist. 2. Recreate batch operations in Operate. -4. **Permanent Region Setup:** Follow the [operational procedure to create a new permanent region](./../../operational-guides/multi-region/dual-region-ops.md#failback) that will become your new passive region. +4. **Permanent region setup:** Follow the [operational procedure to create a new permanent region](./../../operational-guides/multi-region/dual-region-ops.md#failback) that will become your new passive region. ### Passive region loss The loss of the passive region results in the following: -- **Workflow Engine Impact**: The workflow engine will stop processing due to the loss of quorum. +- **Workflow engine impact**: The workflow engine will stop processing due to the loss of quorum. #### Steps to take in case of passive region loss -1. **Temporary Recovery:** Follow the [operational procedure to temporarily recover](./../../operational-guides/multi-region/dual-region-ops.md#failover) from the loss and unblock the workflow engine. -2. **Permanent Region Setup:** Follow the [operational procedure to create a new permanent region](./../../operational-guides/multi-region/dual-region-ops.md#failback) that will become your new passive region. +1. **Temporary recovery:** Follow the [operational procedure to temporarily recover](./../../operational-guides/multi-region/dual-region-ops.md#failover) from the loss and unblock the workflow engine. +2. **Permanent region setup:** Follow the [operational procedure to create a new permanent region](./../../operational-guides/multi-region/dual-region-ops.md#failback) that will become your new passive region. -**Note:** Unlike an active region loss, no data will be lost and no traffic rerouting is necessary. +:::note +Unlike an active region loss, no data will be lost and no traffic rerouting is necessary. +::: -### Disaster Recovery +### Disaster recovery Based on all the limitations and requirements, you can consider the **Recovery Point Objective (RPO)** and **Recovery Time Objective (RTO)** in case of a disaster recovery to help with the risk assessment. -The **Recovery Point Objective (RPO)** is the maximum tolerable data loss measured in time. +The **RPO** is the maximum tolerable data loss measured in time. -The **Recovery Time Objective (RTO)** is the time to restore services to a functional state. +The **RTO** is the time to restore services to a functional state. -For Operate, Tasklist, and Zeebe the **RPO** is **0**. +For Operate, Tasklist, and Zeebe, the **RPO** is **0**. The **RTO** can be considered for the **failover** and **failback** procedures, both resulting in a functional state. - **failover** has an **RTO** of **< 1** minute to restore a functional state, excluding DNS considerations. - **failback** has an **RTO** of **5 + X** minutes to restore a functional state, where X is the time it takes to back up and restore Elasticsearch. This timing is highly dependent on the setup and chosen [Elasticsearch backup type](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-register-repository.html#ess-repo-types). - During our automated tests, the reinstallation and reconfiguration of Camunda 8 takes 5 minutes. This can serve as a general guideline for the time required, though your experience may vary depending on your available resources and familiarity with the operational procedure. - -:::info - -The described minutes for the **Recovery Time Objective** are estimated and may differ due to the manual steps involved. - -::: + During our automated tests, the reinstallation and reconfiguration of Camunda 8 takes approximately five minutes, though your experience may vary depending on your available resources and familiarity with the operational procedure. ## Guides diff --git a/docs/self-managed/operate-deployment/operate-configuration.md b/docs/self-managed/operate-deployment/operate-configuration.md index 32a38ee879..59bde307f9 100644 --- a/docs/self-managed/operate-deployment/operate-configuration.md +++ b/docs/self-managed/operate-deployment/operate-configuration.md @@ -159,7 +159,7 @@ camunda.operate: To connect to a secured (https) OpenSearch instance, you normally need to only set the URL protocol part to `https` instead of `http`. A secured OpenSearch instance also needs `username` and `password`. -To use AWS Credentials instead of basic auth when connecting to Amazon OpenSearch Services `awsEnabled` has to be set. +To use AWS credentials instead of basic auth when connecting to Amazon OpenSearch Services, `awsEnabled` must be set. The other SSL settings should only be used in case of connection problems; for example, in disabling host verification. @@ -179,7 +179,7 @@ Either set `host` and `port` (deprecated), or `url` (recommended). | camunda.operate.opensearch.ssl.certificatePath | Path to certificate used by OpenSearch | - | | camunda.operate.opensearch.ssl.selfSigned | Certificate was self-signed | false | | camunda.operate.opensearch.ssl.verifyHostname | Should the hostname be validated | false | -| camunda.operate.opensearch.awsEnabled | Should AWS Credentials be used | false | +| camunda.operate.opensearch.awsEnabled | Should AWS credentials be used | false | #### Settings for shards and replicas diff --git a/docs/self-managed/operational-guides/multi-region/dual-region-ops.md b/docs/self-managed/operational-guides/multi-region/dual-region-ops.md index e3bb550778..514e12a1c1 100644 --- a/docs/self-managed/operational-guides/multi-region/dual-region-ops.md +++ b/docs/self-managed/operational-guides/multi-region/dual-region-ops.md @@ -70,13 +70,13 @@ Running dual-region setups requires the users to be able to detect any regional We handle the loss of both active and passive regions using the same procedure. For clarity, this section focuses on the scenario where the passive region is lost while the active region remains operational. -#### Key Steps to Handle Passive Region Loss +### Key steps to handle passive region loss -1. **Traffic Rerouting:** Reroute traffic to the surviving active region using DNS. (Details on how to manage DNS rerouting depend on your specific DNS setup and are not covered in this guide.) -2. **Temporary Loss Scenario:** If the region loss is temporary (for example, due to network issues), Zeebe can survive this loss but may stop processing due to quorum loss. This could lead to persistent disk filling up before data is lost. -3. **Procedure Phases** - - **Failover Phase:** Temporarily restores Camunda 8 functionality by removing the lost brokers and handling the export to the unreachable Elasticsearch instance. - - **Failback Phase:** Fully restores the failed region to its original functionality. This phase requires the region to be ready for the redeployment of Camunda 8. +1. **Traffic rerouting:** Reroute traffic to the surviving active region using DNS. (Details on how to manage DNS rerouting depend on your specific DNS setup and are not covered in this guide.) +2. **Temporary loss scenario:** If the region loss is temporary (for example, due to network issues), Zeebe can survive this loss but may stop processing due to quorum loss. This could lead to persistent disk filling up before data is lost. +3. **Procedure phases** + - **Failover phase:** Temporarily restores Camunda 8 functionality by removing the lost brokers and handling the export to the unreachable Elasticsearch instance. + - **Failback phase:** Fully restores the failed region to its original functionality. This phase requires the region to be ready for the redeployment of Camunda 8. :::warning @@ -137,7 +137,7 @@ desired={}
-| **Current State** | **Desired State** | +| **Current state** | **Desired state** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | You have ensured that you fully lost a region and want to start the temporary recovery.

One of the regions is lost, meaning Zeebe:
- No data has been lost thanks to Zeebe data replication.
- Is unable to process new requests due to losing the quorum
- Stops exporting new data to Elasticsearch in the lost region
- Stops exporting new data to Elasticsearch in the survived region | The lost brokers have been removed from the Zeebe cluster.

Continued processing is enabled, and new brokers in the failback procedure will only join the cluster with our intervention. | @@ -297,10 +297,10 @@ desired={}
-| **Details** | **Current State** | **Desired State** | +| **Details** | **Current state** | **Desired state** | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | -| **Zeebe Configuration** | Zeebe brokers in the surviving region are still configured to point to the Elasticsearch instance of the lost region. Zeebe cannot continue exporting data. | Elasticsearch exporter to the failed region has been disabled in the Zeebe cluster. Zeebe can export data to Elasticsearch again. | -| **User Interaction** | Regular interaction with Camunda 8 is not restored. | Regular interaction with Camunda 8 is restored, marking the conclusion of the temporary recovery. | +| **Zeebe configuration** | Zeebe brokers in the surviving region are still configured to point to the Elasticsearch instance of the lost region. Zeebe cannot continue exporting data. | Elasticsearch exporter to the failed region has been disabled in the Zeebe cluster. Zeebe can export data to Elasticsearch again. | +| **User interaction** | Regular interaction with Camunda 8 is not restored. | Regular interaction with Camunda 8 is restored, marking the conclusion of the temporary recovery. | #### How to get there @@ -393,7 +393,7 @@ desired={}
-| **Details** | **Current State** | **Desired State** | +| **Details** | **Current state** | **Desired state** | | ------------------------ | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Camunda 8** | A standalone region with a fully functional Camunda 8 setup, including Zeebe, Operate, Tasklist, and Elasticsearch. | Restore dual-region functionality by deploying Camunda 8 (Zeebe and Elasticsearch) to the newly restored region. | | **Operate and Tasklist** | Operate and Tasklist are operational in the standalone region. | Operate and Tasklist need to stay disabled to avoid interference during the database backup and restore process. | @@ -502,7 +502,7 @@ desired={}
-| **Details** | **Current State** | **Desired State** | +| **Details** | **Current state** | **Desired state** | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Camunda 8** | Functioning Zeebe cluster within a single region:
Working Camunda 8 installation in the surviving region
Non-participating Camunda 8 installation in the recreated region.
Currently exporting data to Elasticsearch from the surviving region. | Preparing the newly created region to take over and restore the dual-region setup. Stop Zeebe exporters to prevent new data from being exported to Elasticsearch, allowing for the creation of an Elasticsearch backup. | | **Operate and Tasklist** | Operate and Tasklist are operational in the surviving region. | Temporarily scale down Operate and Tasklist to zero replicas, preventing user interaction with Camunda 8 and ensuring no new data is imported to Elasticsearch. | @@ -557,9 +557,9 @@ desired={}
-| **Details** | **Current State** | **Desired State** | +| **Details** | **Current state** | **Desired state** | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **Camunda 8** | Not reachable by end-users and not processing any new process instances. This state allows for data backup without loss. | Remain unreachable by end-users and not processing any new instances. | +| **Camunda 8** | Not reachable by end-users and not processing any new process instances. This state allows for data backup without loss. | Remains unreachable by end-users and not processing any new instances. | | **Elasticsearch Backup** | No backup is in progress. | Backup of Elasticsearch in the surviving region is initiated and being restored in the recreated region, containing all necessary data. Backup process may take time to complete. | #### How to get there @@ -785,10 +785,10 @@ desired={}
-| **Details** | **Current State** | **Desired State** | -| ------------------------ | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | -| **Camunda 8** | Remain unreachable by end-users while restoring functionality. | Enable Operate and Tasklist in both the surviving and recreated regions to allow user interaction with Camunda 8 again. | -| **Elasticsearch Backup** | Backup has been created and restored to the recreated region. | N/A | +| **Details** | **Current state** | **Desired state** | +| ------------------------ | --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | +| **Camunda 8** | Remains unreachable by end-users while restoring functionality. | Enable Operate and Tasklist in both the surviving and recreated regions to allow user interaction with Camunda 8 again. | +| **Elasticsearch Backup** | Backup has been created and restored to the recreated region. | N/A | #### How to get there @@ -841,7 +841,7 @@ desired={}
-| **Details** | **Current State** | **Desired State** | +| **Details** | **Current state** | **Desired state** | | ------------- | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Camunda 8** | Reachable to end-users, but not exporting any data. | Start a new exporter to the recreated region.
Ensure that both Elasticsearch instances are populated for data redundancy.
Separate the initialization step (asynchronous) and confirm completion before resuming the exporters. | @@ -911,9 +911,9 @@ desired={}
-| **Details** | **Current State** | **Desired State** | -| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | -| **Camunda 8** | Reachable to end-users, but currently not exporting any data. Exporters are enabled for both regions, with the operation confirmed to be completed | Reactivate existing exporters that will allow Zeebe to export data to Elasticsearch again. | +| **Details** | **Current state** | **Desired state** | +| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | +| **Camunda 8** | Reachable to end-users, but currently not exporting any data. Exporters are enabled for both regions, with the operation confirmed to be completed. | Reactivate existing exporters that will allow Zeebe to export data to Elasticsearch again. | #### How to get there @@ -943,10 +943,10 @@ desired={}
-| **Details** | **Current State** | **Desired State** | +| **Details** | **Current state** | **Desired state** | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | **Camunda 8** | Running in two regions, but not yet utilizing all Zeebe brokers. Operate and Tasklist redeployed, Elasticsearch exporters enabled. | Fully functional Camunda 8 setup utilizing both regions, recovering all dual-region benefits. | -| **User Interaction** | Users can interact with Camunda 8 again. | Dual-region functionality is restored, maximizing reliability and performance benefits. | +| **User interaction** | Users can interact with Camunda 8 again. | Dual-region functionality is restored, maximizing reliability and performance benefits. | #### How to get there diff --git a/docs/self-managed/setup/deploy/local/c8run.md b/docs/self-managed/setup/deploy/local/c8run.md index b25f04411d..40e56aeebb 100644 --- a/docs/self-managed/setup/deploy/local/c8run.md +++ b/docs/self-managed/setup/deploy/local/c8run.md @@ -60,13 +60,13 @@ All Camunda 8 Run components can be accessed using the username/password combina Tasklist and Operate are available at: -- Tasklist: `http://localhost:8080/tasklist` -- Operate: `http://localhost:8080/operate` +- Tasklist: [http://localhost:8080/tasklist](http://localhost:8080/tasklist) +- Operate: [http://localhost:8080/operate](http://localhost:8080/operate) The following components do not have a web interface, but the URLs may be required for additional configuration: -- Zeebe Gateway: `http://localhost:26500` -- Connectors: `http://localhost:8085` +- Zeebe Gateway: [http://localhost:26500](http://localhost:26500) +- Connectors: [http://localhost:8085](http://localhost:8085) :::note The Connectors URL displays a login page, but cannot be logged into. diff --git a/docs/self-managed/tasklist-deployment/tasklist-configuration.md b/docs/self-managed/tasklist-deployment/tasklist-configuration.md index b9bebab45b..c2c7dd029a 100644 --- a/docs/self-managed/tasklist-deployment/tasklist-configuration.md +++ b/docs/self-managed/tasklist-deployment/tasklist-configuration.md @@ -90,17 +90,17 @@ You may need to import the certificate into JVM runtime. For OpenSearch we also have similar configurations: -| Name | Description | Default value | -| :---------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | -| camunda.tasklist.opensearch.indexPrefix | Prefix for index names. | tasklist | -| camunda.tasklist.opensearch.clusterName | Clustername of OpenSearch. | opensearch | -| camunda.tasklist.opensearch.url | URL of OpenSearch REST API. | http://localhost:9200 | -| camunda.tasklist.opensearch.username | Username to access OpenSearch REST API. | - | -| camunda.tasklist.opensearch.password | Password to access OpenSearch REST API. | - | -| camunda.tasklist.opensearch.awsEnabled |

Use basic authentication or AWS credentials to login.

  • Set to `false` to use basic authentication for OpenSearch, adhering to the global AWS OpenSearch configuration settings.

  • Set to `true` to login with AWS credentials.

| false | -| camunda.tasklist.opensearch.ssl.certificatePath | Path to certificate used by OpenSearch | - | -| camunda.tasklist.opensearch.ssl.selfSigned | Certificate was self-signed. | false | -| camunda.tasklist.opensearch.ssl.verifyHostname | Should the hostname be validated. | false | +| Name | Description | Default value | +| :---------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | +| camunda.tasklist.opensearch.indexPrefix | Prefix for index names. | tasklist | +| camunda.tasklist.opensearch.clusterName | Cluster name of OpenSearch. | opensearch | +| camunda.tasklist.opensearch.url | URL of OpenSearch REST API. | http://localhost:9200 | +| camunda.tasklist.opensearch.username | Username to access OpenSearch REST API. | - | +| camunda.tasklist.opensearch.password | Password to access OpenSearch REST API. | - | +| camunda.tasklist.opensearch.awsEnabled |

Use basic authentication or AWS credentials to log in.

  • Set to `false` to use basic authentication for OpenSearch, adhering to the global AWS OpenSearch configuration settings.

  • Set to `true` to log in with AWS credentials.

| false | +| camunda.tasklist.opensearch.ssl.certificatePath | Path to certificate used by OpenSearch | - | +| camunda.tasklist.opensearch.ssl.selfSigned | Certificate was self-signed. | false | +| camunda.tasklist.opensearch.ssl.verifyHostname | Should the hostname be validated. | false | By default, Tasklist always tries to connect to Elasticsearch. To define the database to use, the configuration below is mandatory (if this configuration is missed, Elasticsearch is used as the selected database): diff --git a/docs/self-managed/zeebe-deployment/operations/cluster-scaling.md b/docs/self-managed/zeebe-deployment/operations/cluster-scaling.md index 8fd4c07332..379359c94d 100644 --- a/docs/self-managed/zeebe-deployment/operations/cluster-scaling.md +++ b/docs/self-managed/zeebe-deployment/operations/cluster-scaling.md @@ -369,11 +369,11 @@ curl --request POST 'http://localhost:9600/actuator/cluster/brokers?dryRun=true' -d '["0", "1", "2", "3"]' ``` -##### Replication Factor +##### Replication factor The replication factor for all partitions can be changed with the `replicationFactor` request parameter. If not specified, the replication factor remains unchanged. -The new replicas will be assigned to the brokers based on the round robin partition distribution strategy. +The new replicas are assigned to the brokers based on the round robin partition distribution strategy. ``` curl --request POST 'http://localhost:9600/actuator/cluster/brokers?replicationFactor=4' \ diff --git a/versioned_docs/version-8.4/self-managed/tasklist-deployment/tasklist-configuration.md b/versioned_docs/version-8.4/self-managed/tasklist-deployment/tasklist-configuration.md index fa0ae6a063..ae0c1cc083 100644 --- a/versioned_docs/version-8.4/self-managed/tasklist-deployment/tasklist-configuration.md +++ b/versioned_docs/version-8.4/self-managed/tasklist-deployment/tasklist-configuration.md @@ -84,17 +84,17 @@ You may need to import the certificate into JVM runtime. For OpenSearch we also have similar configurations: -| Name | Description | Default value | -| :---------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | -| camunda.tasklist.opensearch.indexPrefix | Prefix for index names. | tasklist | -| camunda.tasklist.opensearch.clusterName | Clustername of OpenSearch. | opensearch | -| camunda.tasklist.opensearch.url | URL of OpenSearch REST API. | http://localhost:9200 | -| camunda.tasklist.opensearch.username | Username to access OpenSearch REST API. | - | -| camunda.tasklist.opensearch.password | Password to access OpenSearch REST API. | - | -| camunda.tasklist.opensearch.awsEnabled |

Use basic authentication or AWS credentials to login.

  • Set to `false` to use basic authentication for OpenSearch, adhering to the global AWS OpenSearch configuration settings.

  • Set to `true` to login with AWS credentials.

| false | -| camunda.tasklist.opensearch.ssl.certificatePath | Path to certificate used by OpenSearch. | - | -| camunda.tasklist.opensearch.ssl.selfSigned | Certificate was self-signed. | false | -| camunda.tasklist.opensearch.ssl.verifyHostname | Should the hostname be validated. | false | +| Name | Description | Default value | +| :---------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | +| camunda.tasklist.opensearch.indexPrefix | Prefix for index names. | tasklist | +| camunda.tasklist.opensearch.clusterName | Cluster name of OpenSearch. | opensearch | +| camunda.tasklist.opensearch.url | URL of OpenSearch REST API. | http://localhost:9200 | +| camunda.tasklist.opensearch.username | Username to access OpenSearch REST API. | - | +| camunda.tasklist.opensearch.password | Password to access OpenSearch REST API. | - | +| camunda.tasklist.opensearch.awsEnabled |

Use basic authentication or AWS credentials to log in.

  • Set to `false` to use basic authentication for OpenSearch, adhering to the global AWS OpenSearch configuration settings.

  • Set to `true` to log in with AWS credentials.

| false | +| camunda.tasklist.opensearch.ssl.certificatePath | Path to certificate used by OpenSearch. | - | +| camunda.tasklist.opensearch.ssl.selfSigned | Certificate was self-signed. | false | +| camunda.tasklist.opensearch.ssl.verifyHostname | Should the hostname be validated. | false | By default, Tasklist always tries to connect to Elasticsearch. To define the database to use, the configuration below is mandatory (if this configuration is missed, Elasticsearch is used as the selected database): diff --git a/versioned_docs/version-8.5/self-managed/operate-deployment/operate-configuration.md b/versioned_docs/version-8.5/self-managed/operate-deployment/operate-configuration.md index e259a03310..09132364ff 100644 --- a/versioned_docs/version-8.5/self-managed/operate-deployment/operate-configuration.md +++ b/versioned_docs/version-8.5/self-managed/operate-deployment/operate-configuration.md @@ -152,7 +152,7 @@ camunda.operate: To connect to a secured (https) OpenSearch instance, you normally need to only set the URL protocol part to `https` instead of `http`. A secured OpenSearch instance also needs `username` and `password`. -To use AWS Credentials instead of basic auth when connecting to Amazon OpenSearch Services `awsEnabled` has to be set. +To use AWS credentials instead of basic auth when connecting to Amazon OpenSearch Services, `awsEnabled` must be set. The other SSL settings should only be used in case of connection problems; for example, in disabling host verification. @@ -172,7 +172,7 @@ Either set `host` and `port` (deprecated), or `url` (recommended). | camunda.operate.opensearch.ssl.certificatePath | Path to certificate used by OpenSearch | - | | camunda.operate.opensearch.ssl.selfSigned | Certificate was self-signed | false | | camunda.operate.opensearch.ssl.verifyHostname | Should the hostname be validated | false | -| camunda.operate.opensearch.awsEnabled | Should AWS Credentials be used | false | +| camunda.operate.opensearch.awsEnabled | Should AWS credentials be used | false | #### Settings for shards and replicas diff --git a/versioned_docs/version-8.5/self-managed/tasklist-deployment/tasklist-configuration.md b/versioned_docs/version-8.5/self-managed/tasklist-deployment/tasklist-configuration.md index 3d08bd2ee3..257b40651e 100644 --- a/versioned_docs/version-8.5/self-managed/tasklist-deployment/tasklist-configuration.md +++ b/versioned_docs/version-8.5/self-managed/tasklist-deployment/tasklist-configuration.md @@ -84,17 +84,17 @@ You may need to import the certificate into JVM runtime. For OpenSearch we also have similar configurations: -| Name | Description | Default value | -| :---------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | -| camunda.tasklist.opensearch.indexPrefix | Prefix for index names. | tasklist | -| camunda.tasklist.opensearch.clusterName | Clustername of OpenSearch. | opensearch | -| camunda.tasklist.opensearch.url | URL of OpenSearch REST API. | http://localhost:9200 | -| camunda.tasklist.opensearch.username | Username to access OpenSearch REST API. | - | -| camunda.tasklist.opensearch.password | Password to access OpenSearch REST API. | - | -| camunda.tasklist.opensearch.awsEnabled |

Use basic authentication or AWS credentials to login.

  • Set to `false` to use basic authentication for OpenSearch, adhering to the global AWS OpenSearch configuration settings.

  • Set to `true` to login with AWS credentials.

| false | -| camunda.tasklist.opensearch.ssl.certificatePath | Path to certificate used by OpenSearch. | - | -| camunda.tasklist.opensearch.ssl.selfSigned | Certificate was self-signed. | false | -| camunda.tasklist.opensearch.ssl.verifyHostname | Should the hostname be validated. | false | +| Name | Description | Default value | +| :---------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | +| camunda.tasklist.opensearch.indexPrefix | Prefix for index names. | tasklist | +| camunda.tasklist.opensearch.clusterName | Cluster name of OpenSearch. | opensearch | +| camunda.tasklist.opensearch.url | URL of OpenSearch REST API. | http://localhost:9200 | +| camunda.tasklist.opensearch.username | Username to access OpenSearch REST API. | - | +| camunda.tasklist.opensearch.password | Password to access OpenSearch REST API. | - | +| camunda.tasklist.opensearch.awsEnabled |

Use basic authentication or AWS credentials to log in.

  • Set to `false` to use basic authentication for OpenSearch, adhering to the global AWS OpenSearch configuration settings.

  • Set to `true` to log in with AWS credentials.

| false | +| camunda.tasklist.opensearch.ssl.certificatePath | Path to certificate used by OpenSearch. | - | +| camunda.tasklist.opensearch.ssl.selfSigned | Certificate was self-signed. | false | +| camunda.tasklist.opensearch.ssl.verifyHostname | Should the hostname be validated. | false | By default, Tasklist always tries to connect to Elasticsearch. To define the database to use, the configuration below is mandatory (if this configuration is missed, Elasticsearch is used as the selected database):