jordigilh commented on code in PR #372:
URL:
https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/372#discussion_r1484440685
##########
controllers/profiles/common/object_creators.go:
##########
@@ -157,7 +159,13 @@ func defaultContainer(workflow *operatorapi.SonataFlow)
(*corev1.Container, erro
if err := mergo.Merge(defaultFlowContainer,
workflow.Spec.PodTemplate.Container.ToContainer(), mergo.WithOverride); err !=
nil {
return nil, err
}
- defaultFlowContainer = ConfigurePersistence(defaultFlowContainer,
workflow.Spec.Persistence, defaultSchemaName, workflow.Namespace)
+ if workflow.Spec.Persistence != nil {
Review Comment:
Be
> > > if persistence is `nil` in the workflow, settings are used from
platform CR.
> >
> >
> > Doesn't that break backwards compatibility? I mean, currently a workflow
that doesn't have the persistence field populated is not expecting to have
persistence if the platform contains one.
>
> what do you mean by `currently `? isn't this PR introducing this
capability and we get to define how it functions? how would this break
backwards compatibility?
Because if we define that when persistence is nil, which is the default
value, then it should derive the persistence from the platform if it´s defined,
then workflows that are currently running without persistence (the ones before
merging this PR), will suddently now inherit persistence from the platform even
though they don´t require it.
That´s what I mean by backwards compatibility:
* Currently `persistence=nil` means no persistence, it matches the behavior
that the workflows expect before this PR is merged
* After this PR is merged, then `persistence=nil` means it might have
persistence depending on the platform, whether the workflow requested it or not.
I think that if we have a way to discern if the workflow requires
persistence or not, regardless of the value of the persistence struct, we will
save ourselves all this trouble and just apply what needs to be applied.
--
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]
