-
Notifications
You must be signed in to change notification settings - Fork 42
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
Set selector and label specific to platform service #341
Conversation
/lgtm |
@ricardozanini PTAL, @masayag found an issue where the DI and JS services contain the same endpoints because the label selector resolves to the DI and JS pods.
|
@wmedvede PTAL. |
controllers/platform/k8s.go
Outdated
@@ -196,7 +196,7 @@ func createDeployment(ctx context.Context, client client.Client, platform *opera | |||
|
|||
func createService(ctx context.Context, client client.Client, platform *operatorapi.SonataFlowPlatform, ps services.Platform) error { | |||
lbl := map[string]string{ | |||
workflowproj.LabelApp: platform.Name, | |||
workflowproj.LabelApp: ps.GetServiceName(), |
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.
rather than change the existing label, we should probably create an additional label specific to the service.
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.
Should we maintain the same label for both services?
By looking at the previous deployment of data-index, the label was app.kubernetes.io/name: data-index-service-postgresql
The label for the job-service was app.kubernetes.io/name: jobs-service-postgresql
If we wish to maintain a relationship between the services and the platform, ownerReference seems a better representation of the relations between them.
Raised my concern, but will act based on your decision here.
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.
that may be the case for the tech preview templates, but the operator doesn't set that label. it sets app: <platform.name>
. i'm suggesting we leave that label as-is and add a new service-specific label... maybesonataflow.org/service
?
so the labels would look like this for the related service objects ... using a SonataflowPlatform named test
data index objects
labels:
app: test
sonataflow.org/service: test-data-index-service
job service objects
labels:
app: test
sonataflow.org/service: test-jobs-service
a8caa98
to
5cc9cb6
Compare
With recent version of the PR, it looks like this:
|
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.
requested one small change... otherwise lgtm
controllers/platform/k8s.go
Outdated
@@ -243,7 +250,7 @@ func createConfigMap(ctx context.Context, client client.Client, platform *operat | |||
Name: ps.GetServiceCmName(), | |||
Namespace: platform.Namespace, | |||
Labels: map[string]string{ | |||
workflowproj.LabelApp: platform.Name, | |||
workflowproj.LabelService: platform.Name, |
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.
shouldn't this have both labels set? also, this line should remain as-is... and the new label added. this should match the other objects.
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.
yes, both labels should be added here.
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.
→ kubectl get cm -n sonataflow-infra -l app=sonataflow-platform --show-labels
NAME DATA AGE LABELS
sonataflow-platform-data-index-service-props 1 4m9s app=sonataflow-platform,sonataflow.org/service=sonataflow-platform-data-index-service
sonataflow-platform-jobs-service-props 1 4m8s app=sonataflow-platform,sonataflow.org/service=sonataflow-platform-jobs-service
Signed-off-by: Moti Asayag <[email protected]>
5cc9cb6
to
96ddcaa
Compare
E2E tests on this PR are failing because of the java17 vesion fix send in another commit. |
@@ -34,6 +34,8 @@ const ( | |||
ApplicationPropertiesFileName = "application.properties" | |||
// LabelApp key to use among object selectors, "app" is used among k8s applications to group objects in some UI consoles | |||
LabelApp = "app" | |||
// LabelService key to use among object selectors | |||
LabelService = "sonataflow.org/service" |
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.
@masayag can you please fix this in a follow up PR?
LabelService = metadata.Domain + "/service"
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 done here: #351
Signed-off-by: Moti Asayag <[email protected]>
Signed-off-by: Moti Asayag <[email protected]>
Description of the change:
Set a specific selector for each service installed by the platform.
Closes #340
Motivation for the change:
Having the same selector will cause issues with the service routing to the incorrect pod and also for issues with scaling.
Checklist
How to backport a pull request to a different branch?
In order to automatically create a backporting pull request please add one or more labels having the following format
backport-<branch-name>
, where<branch-name>
is the name of the branch where the pull request must be backported to (e.g.,backport-7.67.x
to backport the original PR to the7.67.x
branch).Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.
If something goes wrong, the author will be notified and at this point a manual backporting is needed.