Hi,
could you please consider interface autoconnection for the maas snap?
The snap currently uses the following interfaces:
The application needs all of them connected to function properly, so it would be a nicer experience for users if they were autoconnected on install.
Thanks,
-Alberto
I don’t doubt this and I believe I can guess, but can you give a sentence or two explanation for what functionality within MAAS requires each of these? Please pay special attention to block-devices and network-control since they are quite powerful. Thanks!
One of the main considerations when granting auto-connection is whether the user will implicitly allow a snap to use powerful and sensitive interfaces. In that respect, my gut feeling would be to +1 auto-connection to the -observe and read-only interfaces, but wondering if, following the pattern we recommend, maas could detect, and inform the user of the need to (and consequences of) connecting manually the more sensitive ones (block-devices and network-control); thus not granting auto-connect for those two so the user can have more control. I’m unsure if there’s a natural point in maas’s installation, setup or operation where this could be done.
Let me know if this sounds feasible/useful, also I’ll wait until the information requested by Jamie is in, and finalize my vote then.
Thanks!
Here’s a bit more details on why we need the different interfaces in MAAS.
I removed the log-observe one, as it turns out we don’t really need it.
avahi-observe: used for network devices discovery. MAAS displays a list of network hosts/devices discovered on the networks it’s connected to
block-devices: MAAS currently uses this on rack controllers to collect information about block devices and partisions. We actually only need read-only access and we’d need to be able to read partition info as well, so a read-only iterface would be enough. See https://bugs.launchpad.net/snapd/+bug/1837369 for the request.
hardware-observe, kernel-module-observe, mount-observe: MAAS rack controllers run a series of tools to gather hardware/system information, including lsblk, lscpu, and collect a list of disks/partitions on the system, along with their details, and a list of modaliases for loaded kernel modules.
network-control: MAAS runs a dhcp server, so it needs low-level access to network devices
network-observe: MAAS needs to get details about network addresses for all interfaces
system-observe: this is used to read /proc/PID/comm in order to find PIDs for all dhclient processes, to track DHCP configuration for network devices
time-control: MAAS runs the chrony deamon to keep system time sync’d across nodes
This would be possible to do when initializing maas via maas init.
It would be nice if it were possible to get the connection status of interfaces (e.g. via snapctl), rather than have to have some code that tries to perform some action and report if it fails.
MAAS won’t work correctly unless all interfaces are connected, so we’ll have to check for the ones that are not auto-connected, and fail the initialization process if they are not.
We should be able to change our current scripts so that we don’t require the block-devices plug at all.
Would it be acceptable to get the network-control and time-control autoconnected in addition to the observe ones?
Ack, -1 for log-observe then
+1 for avahi-observe
-1 for block-devices since you said elsewhere it is unneeded.
+1 for hardware-observe, kernel-module-observe and mount-observe. Note that lack of mount-observe may not be fatal depending on your snap
+1 for network-control (one would think a dhcp server wouldn’t actually need all of this, but with what kernel capabilities as they are…)
+1 for network-observe
+1 for system-observe
+1 for time-control
@reviewers - can others vote on this?
The request as I understand it was amended for the above interfaces only - +1 from me on the above, they make sense and maas’s functionality is well-explained - would be unlikely for someone to install it unless they really need it so any potential for abuse is minimal.
+0 on the others since they are not needed anymore 
Your list is essentially the same as mine (dropped log-observe and block-devices, left the rest), but you dropped mount-observe. I don’t see where that is no longer needed. @roadmr and @ack - can one of you comment?
@jdstrand we do still need mount-observe. It wasn’t dropped from the list.
To be clear, this would be the updated list we’d like autoconnect for:
My bad - +1 to mount-observe. Thanks for double-checking my list
Cheers,
2 votes for, 0 against for this list. Granting auto-connection. This is now live.
Many thanks! (sorry for the delay, was on holiday)
