Open nexus49 opened 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.
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.
@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?
👋
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
What happened: So when creating a OCM Component based on the given resource file:
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:
When this OCM Component is being used to be deployed using the ocm controller you'd define the following resource:
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
orexample.com/repo/ocm/github.com/example-org/example-repo/example-chart
in the given example.