wmedvede commented on PR #467:
URL:
https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/467#issuecomment-2166379601
Hi @jianrongzhang89 , here goes some more test results with the latest
changes:
**Case 2)** Is still failing
https://github.com/flows-examples/techpreview2/tree/main/platforms/data_index_and_jobservice_as_platform_service_postgresql_persistence_knative_eventing/case2
After deploying the DI, JS, and the workflow, we have same outcome as before:
```
kubectl get workflow -n case2-kn-eventing
NAME PROFILE VERSION URL READY REASON
callbackstatetimeouts preview 0.0.1 False DeploymentFailure
```
**Case 5)** is now working with the following considerations:
https://github.com/flows-examples/techpreview2/tree/main/platforms/data_index_and_jobservice_as_platform_service_postgresql_persistence_knative_eventing/case5
**Trigger names collision:**
When we use the SFCP, with the cluster-wide instance of the DI, JS, and
Broker, all the triggers must be created in the namespace of the SFP that
defines these objects. (in the example case5-kn-eventing). This is necessary
from the point of view of Knative Eventing.
And thus, if we deploy a workflow "callbackstatetimeouts" in namespace1, a
trigger with the name callbackstatetimeouts-callbackevent-trigger will be
created in "case5-kn-eventing".
Now, if we deploy "callbackstatetimeouts" in nampespace2, the operator will
try to create callbackstatetimeouts-callbackevent-trigger in
"case5-kn-eventing" and will produce an error.
The error only happens of course when we use that cluster-wide configuration.
Well, considering that we are doing work in parallel, to support the same
workflow name to be deployed in different namespaces, I think this trigger
issue, must be fixed as part of this PR. Not too much really.
**note:** we should include the namespace in the trigger name only for
workflows that are deployed in a different ns I think.
**Trigger names length:**
It looks like the Trigger names, IDK why, must be no longer than 63
characters. With a larger name, it looks like the trigger is created, but, it
doesn't work. And, by querying triggers with "kn trigger list", we can see the
following output.
`sonataflow-broker service:sonataflow-platform-data-index-service 9s
3 OK / 6 False NotSubscribed : Subscription.messaging.knative.dev
"sonataflow-broker-sonataflow-pla6ff7c12b8027f7bef859225cc5ef7cf" is invalid:
metadata.labels: Invalid value:
"sonataflow-platform-data-index-service-process-def-triggerssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff":
must be no more than 63 characters`
Considering that we are not that far to reach that limit, think we must:
1) Ask if this is an error in Knative Eventiing. Why so short trigger
names?. Maybe in some newer version this was fixed, or mabye this is needed.
Mabye the rational for that limit is this:
https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#:~:text=in%20RFC%201035.-,This%20means%20the%20name%20must%3A,start%20with%20an%20alphabetic%20character
2) If that length is there for good reasons, we must apply a smart trimming
of the names for the generated Triggers, otherwise the probability of a failure
is huge and the integration won't work.
On the other hand, the SinkBinding names looks to support 253 characters
like other k8s objects.
--
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]
