provider: only store resource if spec has changed

[arkodg]

Leverage the metadata.Generation field to consider whether to update the newly reconciled resource into the watchable map which will trigger translations in the backend.

Fixes: #407

Signed-off-by: Arko Dasgupta arko@tetrate.io

[codecov-commenter]

Codecov Report

Merging #480 (d1ded31) into main (c4fbdc0) will decrease coverage by 0.01%.
The diff coverage is 91.30%.

@@            Coverage Diff             @@
##             main     #480      +/-   ##
==========================================
- Coverage   62.51%   62.49%   -0.02%     
==========================================
  Files          42       42              
  Lines        4498     4509      +11     
==========================================
+ Hits         2812     2818       +6     
- Misses       1540     1547       +7     
+ Partials      146      144       -2     

Impacted Files	Coverage Δ
internal/provider/kubernetes/gatewayclass.go	70.28% <ø> (+1.44%)	⬆️
internal/provider/kubernetes/gateway.go	68.92% <89.47%> (-1.25%)	⬇️
internal/provider/kubernetes/httproute.go	62.12% <100.00%> (ø)
internal/gatewayapi/translator.go	91.16% <0.00%> (-0.02%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[arkodg]

blocked on #508

[chauhanshubham]

I remember that if we Patch the subresource the resource version/generation doesn't change (as compared to using Update).
So I think if we consider using a Patch then that too can prevent the endless loop of reconcile -> status update -> reconcile.

I tried by replacing the Status update with

u.client.Status().Patch(context.Background(), newObj, client.MergeFrom(newObj))

and it seems to be working fine for me.

[chauhanshubham]

Also, just checking if the spec has changed, sometimes doesn't go well if users (or other systems) are changing certain metadata fields like annotations or labels, or if a finalizer was added/removed (also deletionTimestamp) let's say.

[danehans]

@arkodg now that #508 and #516 have merged, are you able to update this PR?

[arkodg]

I remember that if we Patch the subresource the resource version/generation doesn't change (as compared to using Update). So I think if we consider using a Patch then that too can prevent the endless loop of reconcile -> status update -> reconcile.

I tried by replacing the Status update with

u.client.Status().Patch(context.Background(), newObj, client.MergeFrom(newObj))

and it seems to be working fine for me.

does Patch not trigger a reconcile ?

[arkodg]

@arkodg now that #508 and #516 have merged, are you able to update this PR?

now its blocked on #535 due to Changs introduced in #518

[arkodg]

Also, just checking if the spec has changed, sometimes doesn't go well if users (or other systems) are changing certain metadata fields like annotations or labels, or if a finalizer was added/removed (also deletionTimestamp) let's say.

for translation, the spec affects a translation change (for now) so imho this approach should be safe for now

[danehans]

@arkodg should the same be done for HTTPRoutes?

[arkodg]

@danehans the diffs in this commit apply to HTTPRoutes as well