[Question] How to create a setter for an item in array?

[flickerfly]

I have the following kustomization.yaml and Krmfile. It includes an array of ENV values that I'd like to turn into setters. So far the best I can figure out is a single setter for the entire array. Can I set list items in the array individually?

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namePrefix: minecraft-bedrock-
namespace: bedrock
resources:
- manifests/service.yaml
- manifests/statefulSet.yaml
configMapGenerator:
- name: minecraft-bedrock
  literals: # {"$openapi":"configMapGenerator.name"}
  - EULA="FALSE" # Must accept EULA to use this minecraft server (Set to TRUE)
  - GAMEMODE="survival" # Options=survival, creative, adventure
  - DIFFICULTY="normal" # Options=peaceful, easy, normal, hard
  - DEFAULT_PLAYER_PERMISSION_LEVEL="member" # Options=visitor, member, operator
  - LEVEL_NAME="my_minecraft_world"
  - LEVEL_SEED="33480944"
  - SERVER_NAME="my_minecraft_server"
  - SERVER_PORT="19132"
  - LEVEL_TYPE="DEFAULT" # Options=FLAT, LEGACY, DEFAULT
  - ALLOW_CHEATS="false" # Options=true, false
  - MAX_PLAYERS="10"
  - PLAYER_IDLE_TIMEOUT="30"
  - TEXTUREPACK_REQUIRED="false" # Options=true, false
  - OPS=""
  - MEMBERS=""
  - VISITORS=""
  - ONLINE_MODE="true"
  - WHITE_LIST="false"
  - WHITE_LIST_USERS="commma,separated,names"
  - VIEW_DISTANCE="10" # Performance impact
  - TICK_DISTANCE="4" # Performance impact
  - MAX_THREADS="8" # Performance impact

Krmfile

apiVersion: config.k8s.io/v1alpha1
kind: Krmfile
openAPI:
  definitions:
    io.k8s.cli.setters.configMapGenerator.name:
      type: array
      x-k8s-cli:
        setter:
          name: configMapGenerator.name
          value: ""
          description: "Set Configuration array for Minecraft Bedrock server"
          listValues:
          - EULA="FALSE"
          - GAMEMODE="survival"
          - DIFFICULTY="normal"
          - DEFAULT_PLAYER_PERMISSION_LEVEL="member"
          - LEVEL_NAME="my_minecraft_world"
          - LEVEL_SEED="33480944"
          - SERVER_NAME="my_minecraft_server"
          - SERVER_PORT="19132"
          - LEVEL_TYPE="DEFAULT"
          - ALLOW_CHEATS="false"
          - MAX_PLAYERS="10"
          - PLAYER_IDLE_TIMEOUT="30"
          - TEXTUREPACK_REQUIRED="false"
          - OPS=""
          - MEMBERS=""
          - VISITORS=""
          - ONLINE_MODE="true"
          - WHITE_LIST="false"
          - WHITE_LIST_USERS="commma,separated,names"
          - VIEW_DISTANCE="10"
          - TICK_DISTANCE="4"
          - MAX_THREADS="8"
          required: true

[phanimarupaka]

@flickerfly Thanks for the question. Firstly, are you using setters with kustomize or kpt? If kustomize what is the actual command you used to create the setter for entire array ?

[flickerfly]

I'm trying to see if I can stick with Kustomize for this (know it is Alpha).

If my bash history is correct, this is the command I issued.

kustomize cfg init base/
kustomize cfg create-setter . configMapGenerator.name [EULA="FALSE",GAMEMODE="survival",DIFFICULTY="normal",DEFAULT_PLAYER_PERMISSION_LEVEL="member",LEVEL_NAME="my_minecraft_world",LEVEL_SEED="33480944",SERVER_NAME="my_minecraft_server",SERVER_PORT="19132",LEVEL_TYPE="DEFAULT",ALLOW_CHEATS="false",MAX_PLAYERS="10",PLAYER_IDLE_TIMEOUT="30",TEXTUREPACK_REQUIRED="false",OPS="",MEMBERS="",VISITORS="",ONLINE_MODE="true",WHITE_LIST="false",WHITE_LIST_USERS="commma,separated,names",VIEW_DISTANCE="10",TICK_DISTANCE="4",MAX_THREADS="8"] --type array --required --field literals

[phanimarupaka]

@flickerfly Cool. Setters are not fully supported in kustomize yet but great to see you use it.

You can do the same to target a particular value.

kustomize cfg create-setter . configMapGenerator.name 'EULA="FALSE"'

[phanimarupaka]

@flickerfly Did that answer your question?

[flickerfly]

I don’t see it actually working.

[phanimarupaka]

@flickerfly Ahh I see... I wouldn't recommend you to use setters with kustomize. They are not fully supported/documented and will be deprecated soon. Have you tried using kpt instead ? Please try using kpt
https://googlecontainertools.github.io/kpt/installation/
https://googlecontainertools.github.io/kpt/guides/producer/setters/

Here are the steps to perform task above

mkdir flickerfly; cd flickerfly

kpt pkg init .

cat <<EOF >> kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namePrefix: minecraft-bedrock-
namespace: bedrock
resources:
- manifests/service.yaml
- manifests/statefulSet.yaml
configMapGenerator:
- name: minecraft-bedrock
  literals: # {"$openapi":"configMapGenerator.name"}
  - EULA="FALSE" # Must accept EULA to use this minecraft server (Set to TRUE)
  - GAMEMODE="survival" # Options=survival, creative, adventure
  - DIFFICULTY="normal" # Options=peaceful, easy, normal, hard
  - DEFAULT_PLAYER_PERMISSION_LEVEL="member" # Options=visitor, member, operator
  - LEVEL_NAME="my_minecraft_world"
  - LEVEL_SEED="33480944"
  - SERVER_NAME="my_minecraft_server"
  - SERVER_PORT="19132"
  - LEVEL_TYPE="DEFAULT" # Options=FLAT, LEGACY, DEFAULT
  - ALLOW_CHEATS="false" # Options=true, false
  - MAX_PLAYERS="10"
  - PLAYER_IDLE_TIMEOUT="30"
  - TEXTUREPACK_REQUIRED="false" # Options=true, false
  - OPS=""
  - MEMBERS=""
  - VISITORS=""
  - ONLINE_MODE="true"
  - WHITE_LIST="false"
  - WHITE_LIST_USERS="commma,separated,names"
  - VIEW_DISTANCE="10" # Performance impact
  - TICK_DISTANCE="4" # Performance impact
  - MAX_THREADS="8" # Performance impact
EOF

kpt cfg create-setter . server-name 'SERVER_NAME="my_minecraft_server"'

kpt cfg list-setters .

kpt cfg set . server-name 'SERVER_NAME="my_minecraft_server_2"'

Let me know if this helps solve your issue.

cc @mikebz @monopole Advocating users to use setters in kpt instead of kustomize as they are not fully supported.

[seh]

Advocating users to use setters in kpt instead of kustomize as they are not fully supported.

I have not been able to find any documentation on the proposed replacement for setters. I've seen mention of "search and replace," which is evocative as a name, but does not constitute a design document. Is there anything we can read today about where the parametric facilities are going?

Also, kpt has been afflicted by its own defects that made kustomize a more attractive choice—mostly for its narrower ambition and its comparative stability. Do you consider that situation to have changed?

[flickerfly]

@phanimarupaka I suppose that's my answer. Like @seh mentioned, I'm also curious to see where this will end up within kustomize. I'm more interested in what the future of kustomize/kpt management for some sort of search and replace will look which is why I was messing with it on this toy project. I support some thought towards how to integrate as the current smashing of the two together in alpha is a bit awkward.

[LittleChimera]

@phanimarupaka can you clarify deprecation statement? Is the whole Krmfile going to get deprecated or just some aspects of it?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

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.

[ChristianCiach]

Is the whole Krmfile going to get deprecated or just some aspects of it?

Sad to see that this issue, like so many others, are automatically closed without any kind of answer or resolution.

[k8s-ci-robot]

@flickerfly: 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.

[phanimarupaka]

@natasha41575 Can you please respond to this issue as you have worked on deprecating few commands in kustomize lately.

cc @mikebz

[KnVerey]

As discussed in #3953 we will be deprecating all setter-related functionality in Kustomize.

/close

[k8s-ci-robot]

@KnVerey: Closing this issue.

In response to this:

As discussed in #3953 we will be deprecating all setter-related functionality in Kustomize.

/close

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.