feat: feature flag to not clone secondary resource on access #2364
Conversation
Signed-off-by: Attila Mészáros <csviri@gmail.com>
csviri
changed the title
Signed-off-by: Attila Mészáros <csviri@gmail.com>
| * longer reflect the state on the server in that case. | ||
| */ | ||
| default boolean cloneSecondaryResourcesWhenGettingFromCache() { | ||
| return true; |
There was a problem hiding this comment.
Shouldn't that be false by default since we're using SSA by default now, no?
There was a problem hiding this comment.
Was, thinking about that, and there are pros/cons to that. It quite risky when somebody is migrating to the new version. On the other hand yes, that would be more optimal to have by default.
There was a problem hiding this comment.
The new version will have significant changes… actually, I'm thinking that the change to SSA will require significant rewrite of operators if you need to only send what changes. Right now, most operators send the whole changed resource, not simply what has changed.
For that matter, that's actually kind of what we're pushing towards with the desired state: people compute the whole resource and that's what gets used. It might not be a big deal because these resources' fields are probably managed by the JOSDK reconciler already but I'm wondering how prevalent that actually is.
There was a problem hiding this comment.
Right now, most operators send the whole changed resource, not simply what has changed.
It's not only what changed, but the whole desired state with SSA.
Yes this might need some changes when there is no SSA used already, I mean the changes are made on an existing object. But this should be the way to do it. Seconday resource is read for comparison (matching) and when it is needed as an input for other resources.
I don't think it is such a big deal to migrate, but I can imagine some cases that might not be trivial.
There was a problem hiding this comment.
One thing to consider, though, is that people might not upgrade if they perceive the upgrade requires too many changes without bringing much benefit (i.e. if someone's operator already works correctly, they probably won't upgrade, especially if they need to change things a lot to do so).
There was a problem hiding this comment.
yes, however, that is why we add feature flags.
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Chris Laprun <claprun@redhat.com>
Signed-off-by: Chris Laprun <claprun@redhat.com>
Signed-off-by: Chris Laprun <claprun@redhat.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
No description provided.