Hey 
I’ve been working on a new tool for charm developers called concierge, which enables easy provisioning of charm test & development machines.
The utility, depending on the configuration, does a number of things:
- Installs the Juju snap
- Installs and configures the MicroK8s snap
- Installs kubectl and populates the
$HOME/kube/config with the MicroK8s kubeconfig
- Installs and configures the LXD snap
- Bootstraps Juju onto one or both of LXD/MicroK8s
In order to make sure LXD & Docker play nice, it also sets iptables rules, and adds users from the system to various groups (such as the snap_microk8s group, and the lxd group).
Obviously this is very privileged, but it is a development tool designed to facilitate adjusting low-level system configuration.
Some links:
Looking at the guidelines for classic, it falls into a couple of categories I think:
- juju helpers
- ides (sort of)
- tools for local, non-root user driven configuration of/switching to development workspaces/environments
Many thanks!
Jon
@review-team any chance I can get a look at this? 
Hey @jnsgruk
So I was thinking about this from a number of different perspectives - firstly, given that we now have a strictly confined juju and lxd and microk8s I was going to suggest that it might be possible to stage all of these snaps inside concierge and plug/slot the appropriate -support interfaces and then it may all work as strictly confined. However, then I realised that kubectl itself is using classic confinement, BUT if it is only driving microk8s which itself is within the concierge snap then perhaps it could work under strict confinement as well. Then for the iptables bits you could likely plug firewall-control et al.
So then it begs the question - would this model work? ie. would users expect concierge to play nicely with an existing lxd / microk8s etc snap OR could it possibly bundle all of these itself?
However, even if it does bundle all of these and plug/slot all of these privileged interfaces, what we end up with is something that may as well be under classic confinement anyway - but unlike the case of using classic confinement, the user is not necessarily aware that concierge has all of these permissions - and so perhaps it is better for the user to make this conscious decision and hence to use classic confinement as you already have done.
In that case then, I think the use of classic confinement is justified by the need to execute arbitrary binaries from the host (ie the existing snap installs of lxd,microk8s,juju etc) and I agree that it fits within the existing precendent of juju helpers / tools for local, non-root user driver configuration of development environments - not to mention the various checkbox snaps which as test tools also set this kind of precendent within the store.
But I would be keen to know your thoughts on the strict-mode suggestion - let me know.
I think it’s an interesting idea, but I think it’s likely to lead to much more confusion, and make things quite difficult to troubleshoot - which is sort of the reverse of what I intended for this tool 
I think checkbox is an interesting parallel, and honestly I think making users acknowledge that this is a super privileged thing with --classic is a good idea.
Thanks for the response - I agree, classic ultimately makes more sense for this particular use case. The requirements for classic confinement are understood. I have vetted the publisher. This is now live.
1 Like
Thanks Alex! Much appreciated! 
