Background
In the current Porch architecture, PackageRevision is not a native Custom Resource (CR). Instead, it is handled through an Aggregated API Server, which processes PackageRevision operations dynamically. In this model, labels and annotations defined in the KptFile are propagated under the spec.packageMetadata section when a PackageRevision GEToperation is performed.
With the new Porch re-architecture, PackageRevision will be treated as a pure native Kubernetes CR. This architectural change requires explicit handling to ensure that label and annotation metadata continues to be correctly propagated and visible.
Requirement
When PackageRevision is implemented as a native Custom Resource, we have to make sure KPT file and CR level metadata must be visible in PackageRevision:
KptFile-sourced metadata: All labels and annotations defined in the KptFile of the package shall continue to be propagated and visible.
CR-level metadata: Labels and annotations applied directly on the PackageRevision CR (via standard Kubernetes metadata) shall also be reflected and accessible within the metadata section.
Background
In the current Porch architecture, PackageRevision is not a native Custom Resource (CR). Instead, it is handled through an Aggregated API Server, which processes PackageRevision operations dynamically. In this model, labels and annotations defined in the KptFile are propagated under the spec.packageMetadata section when a PackageRevision GEToperation is performed.
With the new Porch re-architecture, PackageRevision will be treated as a pure native Kubernetes CR. This architectural change requires explicit handling to ensure that label and annotation metadata continues to be correctly propagated and visible.
Requirement
When PackageRevision is implemented as a native Custom Resource, we have to make sure KPT file and CR level metadata must be visible in PackageRevision:
KptFile-sourced metadata: All labels and annotations defined in the KptFile of the package shall continue to be propagated and visible.
CR-level metadata: Labels and annotations applied directly on the PackageRevision CR (via standard Kubernetes metadata) shall also be reflected and accessible within the metadata section.