masayag commented on code in PR #311:
URL:
https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/311#discussion_r1422549174
##########
controllers/platform/services.go:
##########
@@ -58,30 +55,32 @@ func (action *serviceAction) Handle(ctx context.Context,
platform *operatorapi.S
return nil, err
}
- if err := createDataIndexComponents(ctx, action.client, platform); err
!= nil {
- return nil, err
+ if platform.Spec.Services.DataIndex != nil {
Review Comment:
Maybe this was discussed before, so dropping some ideas here:
Perhaps the desired behavior here is more aligned with [k8s
rolloutStrategy](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#deploymentstrategy-v1-apps).
I'd explore the idea of replacing the `Enabled` flag with a
`rolloutStrategy` property.
It leaves more room for introducing behavior types on CR change. In case of
a change should be reflected in the workflows, the `rolloutStrategy` will
determine the behavior. Few values to `rolloutStrategy`:
* Disabled - do nothing when platform CR is changed. this requires some
out-of-sync between platform configuration to what is currently served by the
workflows.
* Recreate - restart all with new configuration
* RollingUpdate - rolling the changes.
* Detached - detaching the service from workflow definition.
I'm also okay with not having it at all, but making the sync-status with the
platform configuration visible is useful for debugging.
For once, I'd go with a single flag or strategy for all of the services and
not per service.
Also, perhaps the future will knative service will not need this type of
handling at all.
--
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]
