An issue was identified in boxcutter where revisions were being re-created periodically even though there was no change in the resolved bundle. This issue was mitigated for the particular input that caused the observed issue: the manifests set .metadata.creationTimestamp and .status, that are either set by the api-server or by controller reconciling the resource. We should ensure that the resources in the revision phases:

• don't have fields normally set by a controller:
  • .status
  • .metadata.finalizers
  • .metadata.ownerReferences
• don't have fields set by the kube-api server:
  • .metadata.creationTimestamp
  • .metadata.uid
  • .metadata.resourceVersion
  • .metadata.generation
  • .metadata.managedFields
  • .metadata.deletionTimpestamp
  • .metadata.deletionGracePeriodSeconds

See fields with "read-only" in their comments for .metadata (https://github.com/kubernetes/apimachinery/blob/master/pkg/apis/meta/v1/types.go#L111)

Open-questions:

• we probably want to allow people to set labels/annotations in the manifests they ship. Labels and annotations can be added/removed dynamically by users or other controllers during the lifetime of the object. We should probably check that we don't get the same issue as labels/annotations change
• should we tried .metadata.finalizers as above? is there ever a scenario where the author would set a finalizer in the install manifest? even if we cannot think of one, should we care if they do?
• should we sanitize the manifests? or should we treat it more as a static analysis and fail with an error?