-
Notifications
You must be signed in to change notification settings - Fork 4
KOGITO-9800: [operator use case] Singleton Jobs Service per Namespace #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KOGITO-9800: [operator use case] Singleton Jobs Service per Namespace #3
Conversation
wmedvede
commented
Sep 13, 2023
* includes: KOGITO-9801: [operator use case] Multiple Workflows with Data Index and Jobs Service
92aa488
to
13ac99b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great content!!
periodSeconds: 30 | ||
successThreshold: 1 | ||
timeoutSeconds: 10 | ||
initContainers: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead, can we use Startup probes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if a startup probe will help here, what we need to check, is that, before the jobs-service initialization begins, the postgres service is available. And this is what the init-postgres init container is trying to do.
But, a startup prob, won't prevent the jobs-service container to wait for the postgres service to start , instead, the jobs-service container will just start, and if the postgres service is not there yet, it'll just fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My concern is that for prod, we can't use busybox
. The Quarkus Health checks won't ping the postgres service?
...s/sonataflow-callbackstatetimeouts-persistence/02-configmap_callbackstatetimeouts-props.yaml
Outdated
Show resolved
Hide resolved
1. Minikube installed | ||
2. kubectl installed | ||
3. SonataFlow operator installed if workflows are deployed | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add the following:
The minikube registry addon must be enabled in order for the workflow images to get stored in the local registry of the container.
minikube addons enable registry
To confirm that the add is enabled:
minikube addons list |grep registry
| registry | minikube | enabled ✅ | minikube |
| registry-aliases | minikube | disabled | 3rd party (unknown) |
| registry-creds | minikube | disabled | 3rd party (UPMC Enterprises) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jianrongzhang89 do you mind also sending a PR here: https://sonataflow.org/serverlessworkflow/latest/cloud/operator/build-and-deploy-workflows.html#building-kubernetes
We are in a transition to apache, we might need to wait a little bit to stabilize. By tomorrow we should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ricardozanini sounds good. I will submit a PR for it.
@ricardozanini The suggestions were added, regarding the startup probe I left a comment, take look please. |
Let's merge it for now since many people are looking for this change. We can try another approach for the startup when implementing the Data Index/Jobs Service controllers in the operator that won't rely on |