You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
What happened?
When deploying a composition which uses a KCL module from an OCI repository,
function-kcl
always usesSource@latest
irrespective of whether a verison is set for the oci source or not.For example both
and
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 requested008d647
, even though008d647
was published nearly an hour aftere74de4b
, ultimately providing the package pull with 2 version strings, the requested, plus the detected.This would cause additional problems for composition or API versioning whereby if an
XRD/v1alpha1
uses composition with moduleoci://ghcr.io/mproffitt/kcl-test
@v0.0.1
, andXRD/v1beta1
usesv0.1.0
, all compositions requiring thev0.0.1
version will automatically upgrade tov0.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, orlatest
used if not otherwise provided.How can we reproduce it?
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
The text was updated successfully, but these errors were encountered: