Generation number doesn't seem correctly set on cached builtin resources.

[davidfestal]

When completing the replication_test.go e2e cache test with replication scenarios of rbac resources (CR / CRB objects), the generation is not equal when comparing original and cached objects.

I added a TODO in the completed test:

kcp/test/e2e/reconciler/cache/replication_test.go

Lines 706 to 716 in cf8a625

	// TODO(davidfestal): find out why the generation is not the same especially for rbacv1. Is it a characteristic of all
	// internal KCP resources (which are not backed by CRDs) ?
	if b.gvr.Group == rbacv1.SchemeGroupVersion.Group {
	unstructured.RemoveNestedField(originalResource.Object, "metadata", "generation")
	unstructured.RemoveNestedField(cachedResource.Object, "metadata", "generation")
	}
	unstructured.RemoveNestedField(cachedResource.Object, "metadata", "annotations", genericapirequest.AnnotationKey)
	if cachedStatus, ok := cachedResource.Object["status"]; ok && cachedStatus == nil || (cachedStatus != nil && len(cachedStatus.(map[string]interface{})) == 0) {
	// TODO: worth investigating:

Maybe the work done for CRD-backed resources in this PR should also be done for built-in resources that support replication ?

[embik]

@p0lyn0mial do you happen to remember if this issue is still up to date and/or valid?

[p0lyn0mial]

@p0lyn0mial do you happen to remember if this issue is still up to date and/or valid?

I think so, we wanted to fix it with kcp-dev/kubernetes#132

[p0lyn0mial]

and the test still (https://github.com/kcp-dev/kcp/blob/main/test/e2e/reconciler/cache/replication_test.go#L683) seems to be removing the "generation" field before comparison.

[kcp-ci-bot]

Issues go stale after 90d of inactivity.
After a furter 30 days, they will turn rotten.
Mark the issue as fresh with /remove-lifecycle stale.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[embik]

/remove-lifecycle stale