lburgazzoli commented on issue #5192: URL: https://github.com/apache/camel-k/issues/5192#issuecomment-2022422791
> > I know that a reconciliation is triggered but does the integration filter apply ? because if so, then the previous and current integration object would have been the same (i.e. same checksum), so the filter would "skip" the event isn't it ? > > Yes, what it would happen is that the Integration would stick in the `Running` phase, so, only applying the traits expected for such execution. Conversely, if there is a change in the digest, the Integration would start from `Initialization` phase, passing through all the phases (rebuilding, if the kit is no longer matching the expected configuration). If we remove the digest "optimization", we'd need to run every time this second flow. I don't think I follow 100% but it's been long time since I had a look at all those internals and I may be completely wrong, so please, bear with me: - if an owned resource changes, I don't think we should get back to the initialization phase, as none of the generated resources should change the behavior of an integration: it is the other way around, so we should re-apply the manifests - if the spec changes directly or indirectly (i.e when the integration platform / integration profile changes) then yes we must move the integration to the initialization phase so I'd rather try to improve on how we can detect such drifts. Now I understand that this may require some more radical changes but in general I'd really like we move toward reducing our dependency on the integration status as it can quickly get out of date. So @squakez for the time being, I'm fine with your proposed solution. -- 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: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
