You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
= Troubleshooting cross-namespace SonataFlow configuration and deployment issues
5
5
6
-
The following are common configuration problems encountered during SonataFlow deployment and direct solutions for verifying persistence and connectivity:
6
+
Use this procedure to resolve configuration and deployment failures when SonataFlow workflows are installed in a namespace separate from the core services, or if the Data Index fails to connect to the PostgreSQL database.
7
7
8
-
. Workflow installed in a different namespace other than where {product-very-short} Orchestartor infrastructure are deployed and configured fails to start.
9
-
+
10
-
You can deploy a workflow to a namespace outside the core SonataFlow services. Use the following steps to enable persistence and connectivity for the workflow:
8
+
.Prerequisites
9
+
* You have administrator privileges to access the OpenShift cluster.
10
+
11
+
.Procedure
12
+
13
+
. Identify required namespaces.
11
14
12
-
Configure network policies for inter-namespace traffic::
15
+
* Retrieve the namespace value where {product-very-short} is running using `oc get backstage -A`.
13
16
14
-
* When deploying a workflow to a namespace outside the core SonataFlow services, you must configure network policies to permit the necessary inter-namespace traffic.
17
+
* Identify the SonataFlow Services Namespace by checking for either a `sonataflowclusterplatform` or `sonataflowplatform` instance.
15
18
+
16
-
The following example shows a `NetworkPolicy` configured to ingress traffic into the workflow namespace:
19
+
[NOTE]
20
+
====
21
+
By default, the SonataFlow namespace must be the same as the {product-very-short} namespace.
22
+
====
23
+
24
+
. If the workflow is deployed to a namespace outside the core SonataFlow services, configure network policies to permit the necessary inter-namespace traffic.
17
25
+
18
26
[source,subs="+attributes,+quotes"]
19
27
----
28
+
# Example `NetworkPolicy` configuration to ingress traffic into the workflow namespace
* Add SonataFlowClusterPlatform Custom Resource as shown in the following configuration:
53
+
. Add `SonataFlowClusterPlatform` Custom Resource as shown in the following configuration:
45
54
+
46
55
[source,yaml]
47
56
----
@@ -56,9 +65,9 @@ spec:
56
65
namespace: $RHDH_NAMESPACE
57
66
----
58
67
59
-
* To allow communication between {product-very-short} namespace and the workflow namespace, add the following network policies:
68
+
. To allow communication between {product-very-short} namespace and the workflow namespace, create the following network policies:
60
69
61
-
.. To allow {product-very-short} services to accept traffic from workflows, create an additional network policy within the {product-very-short} instance namespace.
70
+
.. Allow {product-very-short} services to accept traffic from workflows. Create an additional network policy within the {product-very-short} instance namespace as shown in the following configuration::
.. To allow traffic from {product-very-short}, SonataFlow and Knative, create a network policy within the additional workflow namespace.
91
+
.. Allow traffic from {product-very-short}, SonataFlow and Knative. Create a network policy within the additional workflow namespace as shown in the following configuration:
83
92
+
84
93
[source,yaml]
85
94
----
@@ -107,11 +116,11 @@ spec:
107
116
kubernetes.io/metadata.name: knative-serving
108
117
----
109
118
110
-
* (Optional) Create an `allow-intra-namespace` policy in the workflow namespace to enable unrestricted communication among all pods within that namespace.
119
+
. (Optional) Create an `allow-intra-namespace` policy in the workflow namespace to enable unrestricted communication among all pods within that namespace.
111
120
112
-
Ensure workflow persistence (If required)::
121
+
. If workflow persistence is required, perform the following configuration steps:
113
122
114
-
* Create a dedicated PostgreSQL Secret containing database credentials within the workflow namespace as shown in the following configuration:
123
+
.. Create a dedicated PostgreSQL Secret containing database credentials within the workflow namespace as shown in the following configuration:
115
124
+
116
125
[source,yaml]
117
126
----
@@ -120,7 +129,7 @@ sed -i '/namespace: <your_namespace>/d' secret.yaml
120
129
oc apply -f secret.yaml -n $ADDITIONAL_NAMESPACE
121
130
----
122
131
123
-
* Configure the workflow `serviceRef` property to correctly reference the PostgreSQL service namespace using the `namespace: $POSTGRESQL_NAMESPACE` attribute as shown in the following configuration:
132
+
.. Configure the workflow `serviceRef` property to correctly reference the PostgreSQL service namespace as shown in the following configuration:
124
133
+
125
134
[source,yaml]
126
135
----
@@ -146,23 +155,9 @@ spec:
146
155
`namespace`::
147
156
Enter the namespace where the PostgreSQL server is deployed.
148
157
149
-
Identify required namespaces::
150
-
151
-
* Retrieve the namespace value where {product-very-short} is running using `oc get backstage -A`.
158
+
. If the `sonataflow-platform-data-index-service` cannot connect to the PostgreSQL database on startup, perform the following diagnostic checks:
152
159
153
-
* Identify the SonataFlow Services Namespace by checking for either a `sonataflowclusterplatform` or `sonataflowplatform` instance.
154
-
+
155
-
[NOTE]
156
-
====
157
-
By default, the SonataFlow namespace must be the same as the {product-very-short} namespace.
158
-
====
159
-
160
-
. `sonataflow-platform-data-index-service` cannot connect to PostgreSQL database on startup.
161
-
+
162
-
Diagnose database connection failures by performing the following checks:
163
-
164
-
.. Make sure the PostgreSQL Pod has fully transitioned to a `running` and operational status.
165
-
+
166
-
Allow additional time for the database initialization before expecting related service pods (`DataIndex`, `JobService`) to establish a connection.
160
+
.. Verify that the PostgreSQL Pod has fully transitioned to a `running` and operational status.
161
+
Allow additional time for database initialization before expecting related service pods (`DataIndex`, `JobService`) to establish a connection.
167
162
168
-
.. If the PostgreSQL Server operates in a dedicated namespace (for example, outside {product-very-short}), configure network policies to ingress from the SonataFlow services namespace. Network policies might prevent the DataIndex and JobService pods from connecting to the database.
163
+
.. If the PostgreSQL Server operates in a dedicated namespace (for example, outside {product-very-short}), verify that network policies are configured to allow ingress traffic from the SonataFlow services namespace. Network policies might prevent the Data Index and Job Service pods from connecting to the database.
Copy file name to clipboardExpand all lines: modules/orchestrator/proc-troubleshooting-missing-workflows.adoc
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,19 +7,19 @@ You can perform the following checks to verify the workflow status and connectiv
7
7
8
8
.Prerequisites
9
9
10
-
* You have administrator privileges to access to the OpenShift cluster where {product-very-short} and SonataFlow services are running.
10
+
* You have administrator privileges to access the OpenShift cluster where {product-very-short} and SonataFlow services are running.
11
11
12
12
.Procedure
13
13
14
-
. Check if the workflow uses GitOps profile. The {product-very-short} Orchestrator UI displays only the workflows that use GitOps profile. Make sure the workflow definition and the sonataflow manifests use this profile.
14
+
. Verify if the workflow uses GitOps profile. The {product-very-short} Orchestrator UI displays only the workflows that use this profile. Make sure the workflow definition and the SonataFlow manifests use the GitOps profile.
15
15
16
16
. Verify that the workflow pod has started and is ready. The readiness of a workflow pod depends on its successful registration with the Data Index. When a workflow initializes, it performs the following actions:
17
17
.. It attempts to create its schema in the database (if persistence is active).
18
18
.. It attempts to register itself to the Data Index. The workflow pod remains in an unready state until it successfully registers to the Data Index.
19
19
+
20
-
Check the workflow deployment for additional status and error messages because it might contain status and error details unavailable in the pod log.
20
+
Check the workflow deployment for additional status and error messages that might be unavailable in the pod log.
21
21
22
-
. Check if the workflow pod can reach the Data Index service. Connect to the workflows pod. Send the following GraphQL request to the Data Index:
22
+
. Check if the workflow pod can reach the Data Index service. Connect to the workflows pod and send the following GraphQL request to the Data Index:
Use the Data Index service and namespace as defined in your environment. By default, this is the same namespace where {product-very-short} is installed (for example, {product-very-short}). If your SonataFlow resources are installed in a separate namespace, use `<your_namespace>`. Check if the {product-very-short} pod can reach the workflow service by running the following command:
31
+
Use the Data Index service and namespace as defined in your environment. By default, this is the same namespace where {product-very-short} is installed. If your SonataFlow resources are installed in a separate namespace, use `<your_namespace>`. Check if the {product-very-short} pod can reach the workflow service by running the following command:
. Connect to the {product-very-short} pod. Verify the {product-very-short} pod connection to the Data Index service and inspect the {product-very-short} pod logs for messages from the Orchestrator plugin.
38
+
. Connect to the {product-very-short} pod. Verify its connection to the Data Index service and inspect the {product-very-short} pod logs for messages from the Orchestrator plugin.
39
39
+
40
40
To inspect the logs, identify the {product-very-short} pod and run the following *oc logs* command:
41
41
+
@@ -90,7 +90,7 @@ sonataflow=# select id, name from definitions;
90
90
+
91
91
You must see your workflows listed in the query results.
92
92
93
-
. Make sure you have enabled Data Index and Job Service as shown in the following configuration:
93
+
. Make sure you have enabled Data Index and Job Service in the `SonataFlowPlatform` custom resource (CR) as shown in the following configuration:
= Troubleshooting common workflow deployment errors
5
5
6
-
Refer to the following checks when diagnosing workflow deployment, connectivity, or configuration failures.
6
+
Use these steps to diagnose and resolve common workflow deployment, connectivity, or configuration failures.
7
7
8
-
Workflow deployment fails::
9
-
+
10
-
To understand why your workflow operation fails, examine the container log of the specific workflow instance by running the following command:
8
+
.Procedure
9
+
10
+
. If the workflow operation fails, examine the container log of the specific workflow instance to determine the cause by running the following command:
11
11
+
12
12
[source,terminal]
13
13
----
14
14
$ oc logs my-workflow-xy73lj
15
15
----
16
16
17
-
Workflow fails to reach an HTTPS endpoint because it cannot verify it::
18
-
+
19
-
When your workflow attempts a REST action that fails the SSL certificate check, it might be because the target endpoint uses a Certificate Authority (CA) that the workflow cannot verify.
20
-
This results in an error in the pod log usually looking like this:
17
+
. If the workflow fails to reach an HTTPS endpoint, check the pod log for an SSL certificate verification failure. This occurs if the target endpoint uses a Certificate Authority (CA) that the workflow cannot verify. The resulting error resembles the following:
21
18
+
22
19
[source,yaml]
23
20
----
24
21
sun.security.provider.certpath.SunCertPathBuilderException - unable to find valid certification path to requested target
25
22
----
26
-
+
27
-
To resolve this, load the additional CA certificate into the running workflow container.
23
+
24
+
. To resolve the SSL certificate error, load the additional CA certificate into the running workflow container.
Workflow operations send REST requests to service endpoints. When an endpoint returns an HTTP error, the workflow fails. The user interface displays the HTTP code and the error message. You can use this information to diagnose the failure. Refer to link:https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status[HTTP code documentation] to understand the meaning of specific errors.
6
+
Workflow operations fail when a service endpoint returns an HTTP error code. The user interface displays the HTTP code and error message. See link:https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status[external documentation] for a complete list of HTTP status code meanings.
7
7
8
8
The following table lists common HTTP errors encountered during workflow execution:
0 commit comments