Reference Starlark Function

[kferrone]

I am particularly interested in using this example and modifying for myself: https://github.com/kubernetes-sigs/kustomize/tree/master/plugin/someteam.example.com/v1/starlarkmixer

My issue is the mixer.star file must be relative of where my terminal is. So if I dom something like cd ../ the function will not reference the mixer.start anymore. I honestly would like to place the function in $XDG_CONFIG_HOME/kustomize/functions.

This way I always know where they are and they become reusable.

Here is the files I am using:
mixer.yaml

apiVersion: mmsg
kind: StarlarkMixer
metadata:
  name: mixer-instance
  annotations:
    # super strict here
    # can't use ../ nor can I use /
    config.kubernetes.io/function: |
      starlark:
        path: mixer.star 

conf.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: some-cm
data:
  foo: bar
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: delete-me

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- conf.yaml
transformers:
- mixer.yaml

How can I safely share the mixer file with any function who want to use it?

Shouldn't the reference to these files be like every other kind of reference and be relative to the file it's in. Then the $(pwd) in the terminal would not matter.

[KnVerey]

/assign @KnVerey

[KnVerey]

I agree that the path should not depend on the current working directory. It should be relative to the Kustomization including the transformer config, as we did for exec in #4125.

That said, there is an open proposal that includes deprecating dedicated starlark support: kubernetes/enhancements#2954. Although it has its advantages, it is a problem for us to maintain and notably causes a permanent inconsistency with kubectl kustomize due to the dependencies it requires. We would accept a PR to fix this issue in the meantime, but you may wish to consider using container- or exec-based function invocation instead in light of that (still tentative) plan.

/triage accepted
/kind bug
/unassign

[kferrone]

I was only curious about Starlark. Not too worried if it gets deprecated. I did like the idea of a dedicated scripting language for Kustomize. I am wondering though the direction of plugins vs functions in kustomize? Are plugins and functions two different ideas and one is going to win over the other? Or are they two separate ideas and they will live alongside each other?

[KnVerey]

I'd characterize functions as a subcategory of plugins, and yes, the KEP proposes retaining function-style Exec and Container plugins only, and deprecating the rest. Please read the Motivation section for more background.

[k8s-ci-robot]

@kferrone: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[kferrone]

new updates and new ideas. No need for this issue. Starlark is getting deprecated.