Auto connect request for juju-db:mount-observe

The juju-db snap (mongodb plus mongo tools) already auto connects

  • system-observe
  • network-observe

We’d like to also auto connect mount-observe to allow reading /proc/xxx/mountinfo which is currently denied by apparmor.

While I understand this is a Canonical project, the processes here require reasoning as to why an interface should be automatically connected, before votes are cast. In this case, I feel you haven’t indicated what purpose the interface serves for the Juju-db Snap. What fails without the interface connected, and why is manual connection insufficient?

This is the juju-db snap which packages mongo plus tools like mongo client and mongo top. The normal operation of mongo results in a tonne of syslog spam due to apparmor denials:

May 03 14:21:17 m5520 audit[7193]: AVC apparmor="DENIED" operation="open" namespace="root//lxd-juju-1009e4-0_<var-snap-lxd-common-lxd>" profile="snap.juju-db.daemon" name="/proc/907/mountinfo" pid=7193 comm="ftdc" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000
May 03 14:21:17 m5520 kernel: audit: type=1400 audit(1651580477.001:407): apparmor="DENIED" operation="open" namespace="root//lxd-juju-1009e4-0_<var-snap-lxd-common-lxd>" profile="snap.juju-db.daemon" name="/proc/907/mountinfo" pid=7193 comm="ftdc" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=10000

juju-db is deployed inside a juju controller at bootstrap. The plug is not something an end user could be expected to connect themselves. They expect juju bootstrap to Just Work. We faced similar issues with the network-observe and system-observe plugs and auto connecting those solved the issues.

Hopefully that clarifies?

So you’re saying the only reason is to prevent syslog spam?

I would state for the record that IMO that is not a valid reason for either of the three interfaces (the two you have already been granted, and this request) to be automatically connected. As a community member I am -1 on this, however this is only advisory to those that have the power to really vote (my vote is not officially recognised)

The log spam is a symptom and the rate of it affects people’s deployments. Like other databases, mongo polls mountinfo as part of it’s normal operations (eg in it’s LinuxSystemMetricsCollector). The fact that it can handle not having this information doesn’t mean we do not want to give it access. It’s not unexpected behaviour at all for a database to need to read such info.

+1 from me for granting auto-connect of mount-observe for juju-db - this is not a highly privileged interface and trying to avoid log spam feels like a good user outcome with no particular risk posed by granting the use of mount-observe. Can other @reviewers please vote?

+1 from me as well for auto-connect mount-observe to juju-db. I agree on its value to provide a better user experience.

+2 votes for, 0 votes against, granting auto-connect of log-observe for juju-db. This is now live. (Note I couldn’t see the use of mount-observe in the snap.yaml for the latest revision of juju-db in the store but nonetheless I have granted this - please let us know if this is actually perhaps not required and it can be removed).

Thanks Alex. The version of the juju-db snap which uses this is 4.4/stable. We don’t want to update latest due to older juju controllers pulling from that track and not being compatible with mongodb 4.4

Ok no worries - thanks for the clarification @wallyworld