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

Configured preferences for Supporting Utilities are not preserved when Rancher Desktop is stopped/restarted #1619

Closed
DanHam opened this issue Feb 18, 2022 · 6 comments
Labels
kind/bug Something isn't working platform/linux

Comments

@DanHam
Copy link

DanHam commented Feb 18, 2022

Actual Behavior

I would like symlinks created under ~/.local/bin to the versions of kubectl and nerdctl installed by Rancher Desktop. As such, I have checked the relevant tick boxes under the Supporting Utilities tab.

This works well for me - the links are there while I have Rancher Desktop running and disappear when I close it.

Unfortunately, when I start Rancher Desktop up again, my previous selections aren't preserved i.e. the tick boxes that I selected are now deselected again

Steps to Reproduce

  1. Start Rancher Desktop
  2. Go to 'Supporting Utilities'
  3. Select (for example) the appropriate tick boxes for kubectl and nerdctl
  4. Stop Rancher Desktop
  5. Start Rancher Desktop
  6. Go to 'Supporting Utilities again - the previously selected tick boxes are now deselected

Result

See above

Expected Behavior

Rancher Desktop should preserve my choices for 'Supporting Utilities' across restarts

Additional Information

No response

Rancher Desktop Version

1.0.1

Rancher Desktop K8s Version

v1.22.6+k3s1

Which container runtime are you using?

containerd (nerdctl)

What operating system are you using?

Other Linux

Operating System / Build Version

Fedora 35

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

AppImage

Windows User Only

No response

@DanHam DanHam added the kind/bug Something isn't working label Feb 18, 2022
@evertonlperes
Copy link
Contributor

Thanks for filing @DanHam
It seems to be a known issue: #848
I'll close this one and you can track it on #848 -- Feel free to jump in and share your thoughts in there.

@evertonlperes evertonlperes added the triage/duplicate This issue or pull request already exists label Feb 18, 2022
@jandubois
Copy link
Member

#848 is different: it is about not deleting symlinks (or files) unless they are symlinks created by RD.

This issue is about remembering to create the symlinks again on startup. Right now you have to create them again manually every time.

This is part of a more general rethinking of how symlinks should be managed. Part of the discussion is in #1512.

We plan to move to putting a symlink to the whole directory on the PATH instead of managing symlinks individually, so I'll keep this issue closed, even though it is not yet addressed.

@DanHam
Copy link
Author

DanHam commented Feb 18, 2022

@evertonlperes Hi Everton - I saw that bug and read through it. The bug I am describing is different.

In brief #848 describes how Rancher Desktop is removing symlinks that it doesn't own i.e. symlinks that have been created by the user themselves or another application.

The bug I am experiencing is that my preferences for creating those symlinks are not being preserved across restarts of the Rancher Desktop application i.e. if I select the option to have Rancher Desktop create a symlink for me for kubectl the next time I start the app the option has been deselected again.

Could you please re-open this?

@evertonlperes
Copy link
Contributor

Sure thing, my bad -- reopening!

@evertonlperes evertonlperes reopened this Feb 18, 2022
@evertonlperes evertonlperes removed the triage/duplicate This issue or pull request already exists label Feb 18, 2022
@DanHam
Copy link
Author

DanHam commented Feb 18, 2022

@jandubois I've just read your comment above. I'm going to read through #1512 now to see if this issue is part of the wider discussion being had there.

@DanHam
Copy link
Author

DanHam commented Feb 18, 2022

@evertonlperes Sorry for the to and fro on this.

I've now read through #1512 as per @jandubois suggestion above.

Clearly this is a known issue. I've added my 2cents/thoughts to the discussion there and so am happy for this issue to be closed.

@DanHam DanHam closed this as completed Feb 18, 2022
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 platform/linux
Projects
None yet
Development

No branches or pull requests

3 participants