Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OCI repository ignores version string #208

Open
mproffitt opened this issue Dec 16, 2024 · 1 comment
Open

OCI repository ignores version string #208

mproffitt opened this issue Dec 16, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@mproffitt
Copy link

mproffitt commented Dec 16, 2024

What happened?

When deploying a composition which uses a KCL module from an OCI repository, function-kcl always uses Source@latest irrespective of whether a verison is set for the oci source or not.

For example both

input:
  source = oci://ghcr.io/mproffitt/kcl-test

and

input:
  source = oci://ghcr.io/mproffitt/kcl-test:0.0.1-008d647

become equivelant to oci://ghcr.io/mproffitt/kcl-test:latest where latest is the last commit sorted alphabetically.

This results in compositions failing because an older KCL module has a later tag alphabetically as demonstrated in the log below in which KCL detects e74de4b as being the latest version instead of the requested 008d647, even though 008d647 was published nearly an hour after e74de4b, ultimately providing the package pull with 2 version strings, the requested, plus the detected.

package-runtime {"level":"info","ts":1734304499.4372098,"caller":"fn/fn.go:37","msg":"Running Function","tag":""}
package-runtime the latest version '0.0.1-e74de4b' will be downloaded
package-runtime downloading 'mproffitt/kcl-test:0.0.1-008d647:0.0.1-e74de4b' from 'ghcr.io/mproffitt/kcl-test:0.0.1-008d647:0.0.1-e74de4b'

This would cause additional problems for composition or API versioning whereby if an XRD/v1alpha1 uses composition with module oci://ghcr.io/mproffitt/kcl-test @ v0.0.1, and XRD/v1beta1 uses v0.1.0, all compositions requiring the v0.0.1 version will automatically upgrade to v0.1.0 irrespective of whether this version is compatible with the installed API.

This additionally leads to problems whereby should an alpha composition run a an incompatible KCL module, the module is pulled thousands of times from the OCI repository which can lead to rate limiting in the more extreme cases or where that composition is used over multiple clusters.

In this instance, the version string should be respected if it is present in the input.source definition, or latest used if not otherwise provided.

How can we reproduce it?

  • Create a basic composition which uses a KCL module from an OCI repository, e.g.
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  creationTimestamp: null
  labels:
    owner: mproffitt
    provider: none
  name: kcl-test
spec:
  compositeTypeRef:
    apiVersion: xtest.crossplane.choclab.net/v1alpha1
    kind: TestComposition
  mode: Pipeline
  pipeline:
  - functionRef:
      name: function-kcl
    input:
      apiVersion: krm.kcl.dev/v1alpha1
      kind: KCLInput
      metadata:
        creationTimestamp: null
      spec:
        config: {}
        credentials:
          password: ""
          username: ""
        source: oci://ghcr.io/mproffitt/kcl-test
        target: ""
    step: step-kcl-do-something

Publish a new version of the KCL module, then set the composition function input source to a specific version tag

Note that latest is always used.

What environment did it happen in?

Function version: function-kcl:v0.10.10
Crossplane version: v1.18.1
Kubernetes version: 1.29.2
Kubernetes distribution: kind

@mproffitt mproffitt added the bug Something isn't working label Dec 16, 2024
@Peefy
Copy link
Collaborator

Peefy commented Dec 21, 2024

cc @zong-zhe

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants