Add first class fields to PackageRevision resource for upstream package name, revision, and repository name

[ChristopherFry]

Requesting first class fields are created in the PackageRevision resource for the upstream package name, upstream revision, and upstream repository name.

Using first class fields eliminates the need of clients needing to parse status.upstreamLock in order to find the upstream package name and revision. Parsing the status.upstreamLock field alone isn't enough to find the repository name, so clients today also need to use the repository url and query Repositories to find the repository name (if registered). The three fields are needed to search upstream and downstream packages.

PackageRevision resource today:

apiVersion: porch.kpt.dev/v1alpha1
kind: PackageRevision
metadata:
  name: application-blueprints-7c3f2f699ad3495c48d81287c6f05a3f59ff2ed1
  namespace: default
  resourceVersion: 86bf85e0dcfc0125d39c521411c9f5545b4be2f8
spec:
  lifecycle: Published
  packageName: external-secrets-blueprint
  repository: application-blueprints
  revision: main
status:
  upstreamLock:
    git:
      commit: d5285bc400ecc10eff910a80866246bef0ff198f
      directory: external-secrets
      ref: external-secrets/v0
      repo: https://github.com/GoogleContainerTools/kpt-samples.git
    type: git

[mortent]

So it sounds like the problem here is that there isn't an easy way to go from the status.UpstreamLock to the actual porch package. The reason for this, is that the Kptfile where the upstreamLock is coming from isn't aware of porch, it just provide a reference directly to a package, using the storage format (git, oci, ..) for the package.

I don't think storing information about porch package in the Kptfile is a good direction. It seems to take us in a direction where managing package have to happen through porch. Also, we do allow creation of package through cloning directly from a git repo or a oci repo, in which case the upstreamLock can't be represented as a porch package.

It seems like the direction for supporting this would be for porch to translate from upstreamLock information to porch package references on the fly as a package is read. This would require that porch has enough information to do this mapping and I'm not sure if that will always be true.

[natasha41575]

It seems like the direction for supporting this would be for porch to translate from upstreamLock information to porch package references on the fly as a package is read. This would require that porch has enough information to do this mapping and I'm not sure if that will always be true.

IIRC, this translation is currently happening on the client-side (e.g. on every kpt alpha rpkg update --discover). Unless I am missing something the implementation of this issue seems like it would largely be moving parts of that code from the CLI over to porch. Are there any reasons that the client is better informed or can do the mapping more reliably than porch can?