The prometheus-ovs-exporter and prometheus-ovn-exporter snaps are published by Canonical and maintained by the OVN Engineering team.
The snaps will be part of our monitoring story when using OVN in multiple products, for example Charmed OpenStack.
We would like to request permission to use the system-files interface for various plugs defined in each snaps snapcraft.yaml, and would also like to request auto-connection of these.
So for this particular request, we also need to know what paths are being requested and with what permissions (read vs write) - for posterity I have extracted this from the snapcraft.yaml:
prometheus-ovn-exporter
etc-openvswitch:
interface: system-files
read:
- /etc/openvswitch
# For Unix sockets read-write permissions are needed even though the
# requests over those sockets will be read-only (in order to write a
# request we need write permissions).
var-run-openvswitch:
interface: system-files
write:
- /var/run/openvswitch
run-openvswitch:
interface: system-files
write:
- /run/openvswitch
var-run-ovn:
interface: system-files
write:
- /var/run/ovn
run-ovn:
interface: system-files
write:
- /run/ovn
prometheus-ovs-exporter
etc-openvswitch:
interface: system-files
read:
- /etc/openvswitch
# For Unix sockets read-write permissions are needed even though the
# requests over those sockets will be read-only (in order to write a
# request we need write permissions).
var-run-openvswitch:
interface: system-files
write:
- /var/run/openvswitch
run-openvswitch:
interface: system-files
write:
- /run/openvswitch
Since /var/run is usually a symlink to /run now I wonder if these instances should be combined to just a single entry like the following as these paths are semantically equivalent:
The naming of these interfaces is in-line with the conventions. However, to my knowledge these snaps are not the clear owner of /run/openvswitch - as such, I am not sure this is appropriate for auto-connect since you are requesting write permission in this case. Similarly, /run/ovn is not clearly owned by the prometheus-ovn-exporter snap so I am not sure it is appropriate for auto-connect with write permission either. However if you feel this is absolutely required then please let us know.
So at this stage my votes are:
+1 to use of but not auto-connect of a run-ovn instance of system-files with write permission to /run/ovn and /var/run/ovn for prometheus-ovn-exporter.
+1 to use of and auto-connect of a etc-openvswitch instance of system-files with read permission to /etc/openvswitch for both snaps.
+1 to use of but not auto-connect of a run-openvswitch instance of system-files with write permission to /run/openvswitch and /var/run/openvswitch for both snaps.
I merged the entries for /run/openvswitch and /var/run/openvswitch (same for OVN).
I can automate the connection of those interfaces where needed in OVN charms (when it comes to the write permission) so I think just allowing to use those would be enough.
The exporters just do reads of data but in order to make a read request over a unix socket you need to be able to write to it. Unfortunately, this also means that an exporter running with root privileges will be able to write to this socket which is a security consideration for auto-connecting.
While the exporters are not very useful without being able to access those directories on a classic system, I agree that connecting manually is feasible here.
Hi, I’m +1 on the current decision (autoconnect the read-only plug but not the ones that allow writing in runtime directories) assuming that works well for the snap’s publishers.
+2 votes for use of but not auto-connect of a run-ovn instance of system-files with write permission to /run/ovn and /var/run/ovn for prometheus-ovn-exporter.
+2 votes for use of and auto-connect of a etc-openvswitch instance of system-files with read permission to /etc/openvswitch for both snaps.
+2 votes for use of but not auto-connect of a run-openvswitch instance of system-files with write permission to /run/openvswitch and /var/run/openvswitch for both snaps.