-
Notifications
You must be signed in to change notification settings - Fork 79
[KOGITO-3736] - Reconciler error in Data index controller when Kogito… #643
Conversation
…Runtime is deployed
Codecov Report
@@ Coverage Diff @@
## master #643 +/- ##
==========================================
- Coverage 42.01% 38.52% -3.49%
==========================================
Files 169 150 -19
Lines 9012 6412 -2600
==========================================
- Hits 3786 2470 -1316
+ Misses 4812 3558 -1254
+ Partials 414 384 -30
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
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.
+1 to this refactoring!
@Kaitou786 @vaibhavjainwiz I remember you saying that we had to create another controller because of the unnecessary reconciliations in a scenario where we had lots of support services. I'm assuming that after this PR won't be a problem anymore?
EDIT: @vaibhavjainwiz's comment made this clear.
/jenkins test |
Change detected in the PR, requesting reviews and running pipeline(if required) again |
I had tested it for couple of scenerios. Thing should work as expected. 🤞 |
/jenkins test |
3 similar comments
/jenkins test |
/jenkins test |
/jenkins test |
@vaibhavjainwiz could you please rebase your PR and review the comments? Many thanks! |
Change detected in the PR, requesting reviews and running pipeline(if required) again |
Change detected in the PR, requesting reviews and running pipeline(if required) again |
Change detected in the PR, requesting reviews and running pipeline(if required) again |
pkg/controller/kogitosupportingservice/kogitosupportingservice_controller.go
Outdated
Show resolved
Hide resolved
pkg/controller/kogitosupportingservice/kogitosupportingservice_controller.go
Outdated
Show resolved
Hide resolved
Otherwise the code looks ok, will try it on OCP instance. |
Change detected in the PR, requesting reviews and running pipeline(if required) again |
Change detected in the PR, requesting reviews and running pipeline(if required) again |
Change detected in the PR, requesting reviews and running pipeline(if required) again |
|
||
// Reconcile reconcile Data Index | ||
func (*DataIndexSupportingServiceResource) Reconcile(client *client.Client, instance *appv1alpha1.KogitoSupportingService, scheme *runtime.Scheme) (reconcileAfter time.Duration, err error) { | ||
log.Infof("Reconciling KogitoDataIndex for %s in %s", instance.Name, instance.Namespace) |
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.
Seems to be a duplicit log entry, in the log I see:
{"level":"info","T":"2020-11-05T17:20:54.598Z","logger":"kogitosupportingservice_controller","msg":"Reconciling KogitoSupportingService for data-index in ksuta-test"}
{"level":"info","T":"2020-11-05T17:20:54.608Z","logger":"kogitosupportingservice_controller","msg":"Reconciling KogitoDataIndex for data-index in ksuta-test"}
I think this log can be removed.
One general comment, I have noticed that *-protobuf-files config map is created even when there are no protobuf files in Kogito application. Would it have sense to skip creation of *-protobuf-files config map in that case? |
In the old feature, we always had to create it because the operator wouldn't know if there were protobuf files or not in the service. Now that we fetch for this information, I would say that we could skip this creation. Can you file a JIRA to follow this up? :D |
Reported as https://issues.redhat.com/browse/KOGITO-3779 |
// append volume mount if its not exists | ||
deployment.Spec.Template.Spec.Containers[0].VolumeMounts = | ||
append(deployment.Spec.Template.Spec.Containers[0].VolumeMounts, corev1.VolumeMount{ | ||
Name: cm.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.
Minor? In case config map contains more protobuf files the Name parameter here is duplicated for every volume mount entry for those protobuf files. Shouldn't it be rather unique? Though I haven't see any issue with it so far.
Just realized the name is used to pair volume mounts with volumes.
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.
Seems to work as expected. Approving. One optional comment related to logging duplicity above.
Good job.
…Runtime is deployed
Jira issue : https://issues.redhat.com/browse/KOGITO-3736
Many thanks for submitting your Pull Request ❤️!
Analysis
As analysed provided logs, I have found that Data-index controller called to reconcile with name and namespace of KogitoRuntimeService. I happed because data-index controller is watching for config map whose owner is KogitoRuntime and handler is provided as of type `
EnqueueRequestForOwner`. Any controller should only watch object which it owns not others. But In this data-index controller is watching object which onwed by KogitoRuntime.
Solution:
KogitoRuntime should monitor configMap which it owns and update deployment object of data-index directly if protoBuf config map update. With this change there is no requirement to maintain seperate controller for data-index.
Please make sure that your PR meets the following requirements:
[KOGITO-XYZ] Subject