Unexpected OCI path for a Component

nexus49 commented 1 week ago

What happened: So when creating a OCM Component based on the given resource file:

components:
  - name: github.com/example-org/example-repo/example-chart
    version: 1.0.0
    provider:
      name: Some Provider
    resources:
      - name: chart
        type: helmChart
        input:
          type: helm
          path: charts/example-chart

This component gets transferred to a OCI repository: example.com/repo/ocm

When looking at the ocm component using the ocm cli it looks like this:

ocm get components --repo example.com/repo/ocm github.com/example-org/example-repo/example-chart -oyaml
---
component:
  componentReferences: []
  creationTime: "2024-10-18T09:43:04Z"
  name: github.com/example-org/example-repo/example-chart
  provider: Some Provider
  repositoryContexts:
  - baseUrl: example.com
    componentNameMapping: urlPath
    subPath: repo/ocm
    type: OCIRegistry
  resources:
  - access:
      imageReference: example.com/repo/ocm/github.com/example-org/example-repo/example-chart/example-chart:1.0.0@sha256:6fafeca3d51ebf5fe110a9b5c7d7ffc2892346733d23e96500f171a6e50d3853
      type: ociArtifact
    digest:
      hashAlgorithm: SHA-256
      normalisationAlgorithm: ociArtifactDigest/v1
      value: 6fafeca3d51ebf5fe110a9b5c7d7ffc2892346733d23e96500f171a6e50d3853
    name: chart
    relation: local
    type: helmChart
    version: 1.0.0
  sources: []
  version: 1.0.0
meta:
  schemaVersion: v2

When this OCM Component is being used to be deployed using the ocm controller you'd define the following resource:

apiVersion: delivery.ocm.software/v1alpha1
kind: ComponentVersion
metadata:
  name: example-chart
  namespace: default
spec:
  interval: 10m0s
  component: github.com/example-org/example-repo/example-chart
  repository:
    url: example.com/repo/ocm/github.com/example-org/example-repo/example-chart
  version:
    semver: 1.0.0

Basically I have to use the component name when using the resource file, OCM CLI and in the ComponentVersion.

When looking at the OCI Resource path (access imageReference) it contains an additional example-chart: example.com/repo/ocm/github.com/example-org/example-repo/example-chart/example-chart

This leads to weird behaviors, when one would for example try to use renovate to update the version of a component based on renovate for deployment scenarios.

What you expected to happen: I'd expect that the OCI path follows the same naming format as the component name: repo/componentname or example.com/repo/ocm/github.com/example-org/example-repo/example-chart in the given example.

Skarlso commented 1 week ago

Hello.

The "additional" chart is from the chart name. For example for me:

➜  http-source-controller git:(main) ✗ ocm get components --repo ghcr.io/skarlso github.com/skarlso/podinfo-helm -oyaml
---
component:
  componentReferences: []
  name: github.com/skarlso/podinfo-helm
  provider: skarlso.org
  repositoryContexts:
  - baseUrl: ghcr.io
    componentNameMapping: urlPath
    subPath: skarlso
    type: OCIRegistry
  resources:
  - access:
      imageReference: ghcr.io/skarlso/github.com/skarlso/podinfo-helm/podinfo:6.3.5
      type: ociArtifact
    name: charts
    relation: local
    type: helmChart
    version: 6.3.5
  sources: []
  version: v1.0.0
meta:
  schemaVersion: v2

The additional chart is podinfo. That's the chart's name. It needs to be there so Helm can find the chart. That's a requirements from Helm.

The other requirement from helm is that the tag of the layer is the same as the helm's version. Otherwise the deploy will fail with an error saying that there is a mismatch between the layer tag and the helm version.

That's why in the access ref you see the version is 6.3.5 and NOT the component version as it would be normally.

nexus49 commented 4 days ago

Ok that makes sense.

But I was expecting that i am able to follow the path of the component -not the helm chart- in OCI and can respond to a new version that was pushed using a tool like renovate in order to update the ComponentVersion resource. I can workaround this by using the same versions for chart/component, but seems this is not how it should be.

morri-son commented 4 days ago

@nexus49 In addition to the repository and the component name prefix there needs to be an additional artifact name as otherwise you would get clashes when more than one resource is contained. The naming you see in your example comes from some defaults that are used, when not specifying additional attributes. If you use the input type you can add repository influence the behavior, e.g. not using the chart name from the Charts.yaml or defining an own prefix instead of using the component version. You can have a look here.

If it is about "subscribing" to newer version of a component, the component subscription that we already have may fit to your requirements. @Skarlso I don't find the subscription in the old controllers doc, but only in the one for MPAS. Does this mean this does not work in controllers v1?

Skarlso commented 3 days ago

👋

The replication is definitely there. It seems like it's just not documented. :( Bad me. :D

https://github.com/open-component-model/ocm-controller/pull/485

open-component-model / ocm

Unexpected OCI path for a Component #984