squakez commented on code in PR #5511:
URL: https://github.com/apache/camel-k/pull/5511#discussion_r1603165665
##########
pkg/controller/integration/monitor.go:
##########
@@ -97,6 +98,26 @@ func (action *monitorAction) Handle(ctx context.Context,
integration *v1.Integra
return changed, nil
}
+ // We must skip the rest of operations if the target operator version
is different
+ // from the expected Integration operator version. This is likely
happening
+ // when the user upgrades from an operator version to another. Given
that the new operator may
+ // introduce changes in the Deployment or other resources we cannot
perform the rest of reconciliation safely.
+ if integration.Status.Version != defaults.Version {
Review Comment:
Yes. This is in line with the expected feature we have in this moment, at
least, according to the way we are documenting the upgrade:
https://camel.apache.org/camel-k/2.3.x/contributing/upgrade.html
Yes, it would affect also patches or full compatible version upgrades but it
is the tradeoff to maintain the feature the way it is documented right now. The
alternative that came to my mind was to have a low level control of each new
feature we do introduce at every release. As an example, this one
https://github.com/apache/camel-k/pull/5461 - we may hardcode a rule to enable
it only when the operator is > 2.4.0 (the expected one for the next release),
but, to be honest, it does not sound a right way to proceed either as it would
be a code maintenance hell.
Then, another alternative would be to let the operator to handle the rebuild
transparently (like it was doing before this fix), but, to me it sounds as a
potential problem for those Integration that the user don't want to have an
automatic redeploy on each upgrade and it goes against the users expectation.
My intention is to make this work the way is documented (and expected by the
user). I agree we can and must enhance this part of the software, but in this
occasion I am not really sure how you'd advice to proceed.
--
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]
