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

RKE2 extraMounts still can't be used #524

Closed
hardys opened this issue Dec 16, 2024 · 2 comments · Fixed by #544
Closed

RKE2 extraMounts still can't be used #524

hardys opened this issue Dec 16, 2024 · 2 comments · Fixed by #544
Assignees
Labels
kind/bug Something isn't working priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Milestone

Comments

@hardys
Copy link
Contributor

hardys commented Dec 16, 2024

What happened:
#476 was closed via #504 but AFAICS the configuration format is still incorrect and thus extraMounts still can't be used.

What did you expect to happen:

According to the RKE2 docs, the expected format is:

kube-apiserver-extra-mount: 
   - "/tmp/foo:/root/foo"

When passing a config like:

serverConfig:
    kubeAPIServer:
      extraMounts:
        "/tmp": "/mnt/tmp"

Prior to #504 we saw a format like:

kube-apiserver-extra-mount:
  /tmp: /mnt/tmp

However since the fix we see a format like:

kube-apiserver-extra-mount:
- /tmp=/mnt/tmp

How to reproduce it:

Deploy with a config that specifies extraMounts similar to the serverConfig mentioned above.

Anything else you would like to add:
AFAICS the problem is we use the componentMapToSlice function which is designed to format for environment variables.

Also note we use the same function in the tests, which is probably unwise since we're not actually testing for the expected format.

@hardys hardys added kind/bug Something isn't working needs-priority Indicates an issue or PR needs a priority assigning to it needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Dec 16, 2024
@hardys
Copy link
Contributor Author

hardys commented Dec 16, 2024

/cc @alexander-demicev

@alexander-demicev alexander-demicev added triage/accepted Indicates an issue or PR is ready to be actively worked on. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. and removed needs-priority Indicates an issue or PR needs a priority assigning to it needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Jan 3, 2025
@kkaempf kkaempf added this to the v0.11.0 milestone Jan 3, 2025
@alexander-demicev alexander-demicev self-assigned this Jan 3, 2025
@alexander-demicev alexander-demicev moved this from CAPI Backlog to In Progress (8 max) in CAPI & Hosted Kubernetes providers (EKS/AKS/GKE) Jan 3, 2025
@alexander-demicev
Copy link
Member

@hardys would you be able to test the fix #544?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Development

Successfully merging a pull request may close this issue.

3 participants