docs: replacement of exit command with creation of .kube directory and usage of newgrp

[SuperAayush]

Summary

As discussed in last community meeting a change in the tutorial section under this link in which while getting a error when installing microk8s it is advised to - "To validate the changes you can exit the VM’s shell and log in again." which is not a good practice and can be replaced by using newgrp.

What Should Happen Instead?

Instead of using exit command, a directory named ".kube" can be made if doesn't exit in the current VM and then the commands shown in the screenshot should be copy and pasted in the terminal followed by newgrp microk8s

Reproduction Steps

1. Launch a new VM using multipass launch --name <vm-name> --mem 4G --disk 40G
2. Shell into that VM using multipass shell <vm name>
3. Install microk8s in that VM using sudo snap install microk8s --classic
4. Run microk8s status --wait-ready

Can you suggest a fix?

To overcome this error usage of newgrp is a better than using exit and re-enter

Are you interested in contributing with a fix?

yes

[faizykhalid]

Hey i was trying to reproduce the suggested steps before i make the edit in docs.
I created a new VM of ubuntu 24.04 on qemu/kvm to test it out.
newgrp microk8s doesn't seem to do the trick i had to do su - ubuntu to make it work. Am i missing something or can we add the solution that worked for me ?

[wieso-itzi]

Hi, I would like to point out, that the "getting started" docs on microk8s.io already recommend the user to execute "su - $USER" in order to apply the new group membership, which basically does the same thing as newgrp, and the microk8s command line utility recommends the user to either reboot the system or run newgrp to apply the new group membership. While personally I find it a little weird for the command line utility to suggest a reboot at least the least invasive options are mentioned as well.

The documentation article mentioned is directly tied to an article on discourse.ubuntu.com. Personally, the documentation from the link you mentioned seems dated anyway and I don't know the Ubuntu documentation eco-system enough to know whether they would care about maintaining it in 2 separate places but I guess if you wanted it to be changed, suggesting the change as a comment to the post (or directly editing the post if your trust level on discourse.ubuntu.com is high enough) would be the way to go.

In that sense, maybe it would make sense to close this issue here, since the issue itself is not present within the contents of the repository?