Microstack: auto connection to snapd-control, hypervisor-config


We’re working on a new version of the microstack snap that interacts and controls a number of other snaps (microk8s and openstack-hypervisor) to help assemble an OpenStack cloud. To support this it needs to talk directly to snapd to control installation/refresh etc of required snaps.

The new version is currently in the manual review queue (#246).

In addition, the openstack-hypervisor snap provides a slot to allow control of configuration of the hypervisor that microstack will make use of. I’m not quite sure how auto-connection works between snaps but if its possible to support auto-connection from microstack -> openstack-hypervisor that would be great.


Not surprisingly, snapd-control is super-privileged and in general it is not clear what the requirements are for a snap to be granted use of this. I suppose it is not too different to the use of various other privileged interfaces but I was under the impression that it was preferred to limit its use where possible.

@pedronis @niemeyer as snapd architects, are you able to advise?

For openstack-hypervisor:hypervisor-config, this is a content slot, and content slots are auto-connected for snaps published by the same publisher, so I think this should automatically auto-connect.

1 Like

To provide a little more context; we originally used the default-provider stanza with the content interfaces provided by microk8s and juju to pull in these snaps as part of the microstack install. However we have future use cases where this is not required - microstack will interact remotely with the components rather than locally all in one unit.

This very much depends on how microstack is bootstrapped for use. The snapd-control interface is used to incorporate this feature directly into the snap code rather than having to use the somewhat more fixed content provider approach.

We’re also very much targeting specific microk8s and juju versions so using channels is quite important which we can currently do using default-provider:


I guess for now we could go with manual connection of this interface - is that a possibility?

Discussed with @niemeyer - different approach agreed for this particular need.

Since a different approach was agreed instead of using snapd-control, I am removing this request from our review queue.