[Split from the earlier similar store request to provide access to other Juju locations]
Proving the value of doing random testing on a selection of machines we’ll also need access for the juju binary to kubernetes configuration files - this is read only:
Hi, as for the juju-personal-files, the need for microstack (ostensibly an openstack-based cloud service) to run juju commands (whereas juju is typically a consumer of such service) is not obvious to me - I’m mentioning juju because it’s been said here that juju is what wants to read the .kube directory but I could not find any mention of kubernetes at all in microstack documentation (on an admittedly superficial skim) so I don’t understand why this is required.
@jamespage sorry for the extra trouble, could you please explain a bit more why/how microstack needs access to .kube if it exists, and why it couldn’t be manually connected in case the user knows they need this? (auto-connect for a smoother experience is fine, but I’d like to understand how that works).
+1 on read for .kube. I think it’s OK to have these interfaces now, even if they do look a little out of place with the old way of the snap’s operation.
+1 from me too - +2 votes for, 0 votes against, this is now live. Although for consistency sake I would prefer this personal-files instance to be named dot-kube rather than dot-kubernetes - @jamepage thoughts?
Hmm ok fair enough - it is not a big thing but ideally we would try and be consistent with these things (ie. for $HOME/.foo the plug is named dot-foo rather than dot-foobar).