Support OCI images in addition to git

[bgrant0607]

Support for OCI images would facilitate automated generation and serving of kpt package versions, particularly in production environments. Every Kubernetes cluster must have an OCI registry accessible. OCI registries have more standardized APIs and authentication methods than git providers. OCI images have standardized metadata and file formats. They can be versioned similarly to git, with digests and tags. We would just need a sequential versioning convention.

It's increasingly common for all types of packages to be stored using OCI. Configuration/policy-related examples: https://github.com/oras-project/oras https://carvel.dev/imgpkg/ https://github.com/helm/helm/issues/6068 https://github.com/open-policy-agent/opa/issues/1413 https://github.com/tektoncd/community/blob/main/teps/0005-tekton-oci-bundles.md https://github.com/cnabio/cnab-spec/blob/main/201-representing-CNAB-in-OCI.md https://crossplane.io/docs/v1.2/concepts/packages.html https://werf.io/documentation/v1.2/advanced/bundles.html

[mikebz]

@phanimarupaka @droot @mengqiy bumping this up since we got a customer request on for non-git package sources.

[mikebz]

could be good to fit this into a larger roadmap and reference this request, I know that the work to do non-git upstream and support resource-merge is not trivial.

[bgrant0607]

Yet another example where this would be useful: https://cloud.google.com/migrate/anthos/docs/migctl-reference#migctl-artifacts-repo-create

[bgrant0607]

We will eventually want to support signing and verification. https://helm.sh/docs/topics/provenance/

[bgrant0607]

Another example: https://kustomizer.dev/

[stoetti]

Is there some kind of ETA for this feature?

[newtondev]

+1 on ETA for this feature please. Our environment is very restrictive and does not allow pull from github in our pipelines.