Spike: OCM v2 migration — evaluate impact on packaged components, SDK usage and ocm-kit

[rebEllieous]

Motivation

OCM v2 (ocm2 CLI 0.12, bindings ocm.software/open-component-model/bindings/go/*) changes both the on-registry layout of transferred components and the Go API surface. Solar consumes OCM in multiple places, so a migration cannot be done in isolation. Before committing to it, we need to know what breaks and which transfer layout we standardise on.

Ilja did some experimentation on the v2 transfer format here: https://gitlab.opendefense.cloud/odc/oscp/notes/-/blob/main/ocmv2/transfer.md?ref_type=heads

The three key v2 differences:

1. Default transfer is localBlob. All OCI images of a component land inside one multi-manifest OCI artifact under /component-descriptors/. The resource access becomes LocalBlob/v1 with a localReference digest; the pullable reference must be assembled as /component-descriptors/:@. Images lose their identity, nothing in a Kubernetes manifest says "podinfo" any more.
2. --upload-as ociArtifact restores ociArtifact/v1 accesses with readable image references. But flat in the target repo (/stefanprodan/podinfo:6.9.1), i.e. exactly the ocm-kit v1-without-mapping behaviour we explicitly did not want, with collision potential across components.
3. Layout is only controllable via a transfer spec. ocm2 transfer cv --dry-run -o yaml … > spec.yaml, edit transformations[*].spec.targetResource.access.imageReference, then ocm2 transfer cv --copy-resources --transfer-spec spec1.yaml. Verified to produce //stefanprodan/podinfo:6.9.1

Questions this spike must answer

1. Can the target layout be driven programmatically? a mapping rule / plugin hand-editing a generated spec.yaml per component? If not, what is the minimum tooling we would have to own?
2. Which layout do we standardise on: localBlob (self-contained, opaque images), ociArtifact + transfer spec (readable, namespaced), or both depending on target?

ACs

• A reproducible experiment: ocm-demo component transferred with v2 in each candidate layout, plus the resulting get cv -o yaml output
• A list of Solar code sites that must change (discovery, handler/helm, renderer, component_types.go, Makefile targets, e2e fixtures)
• A go/no-go recommendation including whether ocm-kit v2 needs upstream fixes/releases first.