Looking at the associated Launchpad bug report there seems to be a genuine need for this use-case. Given the snap is not the owner of this path though, read access seems most appropriate.
However, on the question of auto-connect - can you describe which data is being access from this folder by juju? Since I expect it may potentially contain secrets or other things and so perhaps it is best that this is manually connected by the user when they know they wish to use juju with minikube? Thanks.
So, juju will need at least the CA cert, but we might be using something else (maybe @wallyworld or @hpidcock can provide more info):
$ juju add-k8s m
ERROR detecting clouds for provider "kubernetes": detecting local kube config clouds: getting cluster CA data: open /home/nicolas/.minikube/ca.crt: permission denied
Indeed in ~/.minikube there will be secrets but this is the same case as for ~/.aws for example, which juju already reads and gets auto connected. Since juju users do not have to manually connect the personal config files for other clouds, IMO doing it only in the case of minikube seems confusing. Do you think it’s a bad idea?
I think there is a good argument that auto-connecting ~/.minikube is most likely (like with microk8s) to be used for local-development.
Juju itself does not directly know about ~/.minikube, but it is through ~/.kube/config that is configured by minikube. Minikube inserts a user and cluster stanza into the ~/.kube/config file that use paths (under ~/.minikube) for the cluster certificate-authority and the user client-certificate +client-key.
Example paths are:
NOTE: the profiles sub-directory can contain many different minikube profiles, i.e. the user can create many local minikube clusters, and use any one of them, default is just the default profile name.
As @alexmurray said we must be very cautious when granting access to folders that are not clearly owned by the snap, specially if they contain secrets. However, I think that users should expect that juju , as a orchestration engine, has access to the secrets required to authenticate against the different supported infrastructures/clouds.
Thus, I’ll be happy (+1 from me) to support the request for auto-connection for the following directories
I think its ideal so we reduce the access scope while allowing juju to properly operate. @nvinuesa do you think this is enough or there might be further files/folders inside $HOME/.minikube that juju might require?
Until this request is granted, new uploads to the store which declare such a personal-files interface will be blocked (as the current revisions are anyway) - so feel free to change this on your side and once the request is granted it will then pass automated review.