[Enhancement] Support annotation to set the plain http for the crossplane kcl function

[Peefy]

What problem are you facing?

OCI Source is managed by function kcl and should be able to be set through the fields of KCLRun, in theory something like this perhaps.

    functionRef:
      name: kcl-function
    input:
      apiVersion: krm.kcl.dev/v1alpha1
      kind: KCLRun
      metadata:
        name: basic
        annotations:
          kcl-something/allow-insecure-source: True
      spec:
        target: Resources
        source: oci://localhost:7900/my-composition-kcl:0.0.1

How could this Function help solve your problem?

[Peefy]

More information can be found here https://github.com/crossplane-contrib/function-kcl/issues/43#issuecomment-2006852958

[markphillips100]

Hi @Peefy. When can we expect a release with this PR?

[Peefy]

Hi @markphillips100 I've released function-kcl v0.3.3 for this issue. When we close this local path import issue https://github.com/kcl-lang/krm-kcl/issues/42 and we will release v0.3.4

[markphillips100]

Thank you @Peefy

[markphillips100]

@Peefy I've just tried v0.3.3 using the below yaml and got into problems.

If I use krm.kcl.dev/allow-insecure-source: true and apply the composition manifest I get the familiar error Invalid value: map[string]interface {}{"annotations":map[string]interface {}{"krm.kcl.dev/allow-insecure-source":true}, "name":"basic"}: json: cannot unmarshal bool into Go struct field ObjectMeta.annotations of type string.

If I use krm.kcl.dev/allow-insecure-source: "true" then applying the composition gives no parsing error however the source request is still using https: Get "https://host.docker.internal:7900/v2/tuckerbox/country-composition-kcl/tags/list": http: server gave HTTP response to HTTPS client - note I am using host.docker.internal rather than localhost in order to access the host's docker registry.

Composition:

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: my-composite
spec:
  compositeTypeRef:
    apiVersion: tuckerbox.com/v1alpha1
    kind: MyComposite
  mode: Pipeline
  pipeline:
  - step: normal
    functionRef:
      name: kcl-function
    input:
      apiVersion: krm.kcl.dev/v1alpha1
      kind: KCLRun
      metadata:
        name: basic
        annotations:
          krm.kcl.dev/allow-insecure-source: "true"
      spec:
        target: Resources
        source: oci://host.docker.internal:7900/tuckerbox/my-composition-kcl:0.0.1

Function:

apiVersion: pkg.crossplane.io/v1beta1
kind: Function
metadata:
  name: kcl-function
spec:
  package: xpkg.upbound.io/crossplane-contrib/function-kcl:v0.3.3

[Peefy]

I'm very sorry, I have released v0.3.4 and tested it locally. v0.3.3 version has some issues.

[markphillips100]

One step forward. I can at least see from my local docker registry logs that the kcl function is downloading the oci package fine. However, I think that by now forcing non-ssl for the http request we have introduced an issue for other packages from legitimate registries, i.e. ghcr.io for example.

I used the command kcl mod add k8s as it is needed I think for me to include the schemas generated from crossplane azure provider (I get compile errors if I don't include it).

My kcl.mod has the following:

[dependencies]
k8s = "1.29"

and kcl.mod.lock accordingly has:

[dependencies]
  [dependencies.k8s]
    name = "k8s"
    full_name = "k8s_1.29"
    version = "1.29"
    sum = "L8gHVh822FwrQGsibx6qHRqisIekluCkMpkUO+tULXE="
    reg = "ghcr.io"
    repo = "kcl-lang/k8s"
    oci_tag = "1.29"

The error I see now is the following: Message: cannot compose resources: pipeline step "normal" returned a fatal result: failed to run kcl function pipelines: failed to compile the kcl package failed to get package with '1.29' from 'ghcr.io/kcl-lang/k8s' failed to resolve 1.29: Get "https://ghcr.io/v2/kcl-lang/k8s/manifests/1.29": tls: failed to verify certificate: x509: certificate signed by unknown authority

I'm not 100% positive this is related as the url shows it to be using "https" scheme. The error almost implies that the controller pod doesn't have a root certificate for ghcr.io?

[Peefy]

cc @zong-zhe

[markphillips100]

@Peefy any progress?

[Peefy]

cc @zong-zhe

[zong-zhe]

Hi @markphillips100 😊

Sorry for the delayed response. I was preoccupied with other matters last week, and I am currently addressing this issue.

[markphillips100]

@zong-zhe no need for apologies, support has been fantastic. I'm available whenever you want me to test.

[zong-zhe]

Hi @markphillips100

Can you provide some more details about your context environment at the time this error message was raised?

I used the example in this repository on my local macos and did not reproduce the problem you raised.

The example I used is https://github.com/crossplane-contrib/function-kcl/tree/main/examples/resources/basic

I made some hack, packaged the KCL code used in it into a package named bbb, and made bbb rely on ghcr.io/kcl-lang/k8s:1.29, and uploaded bbb to my local http://localhost:5001.

In the log output from the background, we can see that it successfully downloaded the package and compiled.

If you run it in a k8s cluster, I found some docker pull & k8s problems, the output of the error message is same, the KCL download process follows the same standards as docker pull, so hope this can help to you.

• https://github.com/kubernetes/kubernetes/issues/43924

[markphillips100]

Thanks for the respone @zong-zhe.

I think I may have a crossplane init issue. Seeing the following from a crossplane init container which then makes me think the crossplane ca-certificates is not updated:

crossplane: error: cannot initialize core: cannot load or generate certificate signer: cannot get TLS secret: crossplane-root-ca: failed to get API group resources: unable to retrieve the complete list of  │
│ Stream closed EOF for crossplane-system/crossplane-57cb498b78-n42cj (crossplane-init)

I'll get back to you once I rebuild innerloop and see if the init container is resolved properly. Might even go back to crossplane 1.15.0 if that doesn't work.

My environment: Windows11 Docker Desktop v4.18.0 (using WSL2) registry:2 KinD k8 cluster for kubernetes v1.28.0 Crossplane v1.15.1

[markphillips100]

Well no idea why that happened. All I did was a fresh rebuild of my innerloop - I purge docker desktop and run a script to setup KinD with crossplane, etc. This time no init error from crossplane and no issue from kcl-function.

Seeing this in the kcl-function pod logs so all good:

pulling '/tuckerbox/country-composition-kcl:0.0.1:0.0.1' from 'host.docker.internal:7900/tuckerbox/country-composition-kcl:0.0.1'                                                                             │
│ {"level":"info","ts":1711445041.6634905,"caller":"fn/fn.go:174","msg":"Successfully processed crossplane KCL function resources","tag":"","xr-version":"tuckerbox.com/v1alpha1","xr-kind":"CountryComposite", │
│ {"level":"info","ts":1711445101.687637,"caller":"fn/fn.go:33","msg":"Running Function","tag":""}

Sorry to have wasted your time @zong-zhe and @Peefy

[Peefy]

It doesn't matter. Welcome to communicate anytime.

[markphillips100]

Thank you. Feel free to close....for definite this time.