Hi 
This is my first time creating a snap and I’m not sure if those two requests (manual review and auto-connect) should be split.
I tried to upload my snap into the edge channel and received the message that I need a manual review. The details are in this link.
Regarding the auto-connect requests, OpenSearch (fork project from ElasticSearch) makes heavy use of the local filesystem to store indices and monitor properties like free disk space. Not using the mount-observe interface result in errors logs like this.
The system-files interface is used to read the max_map_count property located at /proc/sys/vm/max_map_count and it’s a important setting for the project.
The snap can be fount at: https://github.com/canonical/opensearch-snap and the code used is currently at PR stage.
Thanks
Using system-files for files under /proc is not exactly what this interface was intended for - instead I think it would be better to update an existing snapd interface to include this access. Would you be interested in submitting a PR to snapd to include this? Perhaps this might be appropriate in the system-observe interface?
+1 from me for auto-connect of mount-observe for opensearch - this is standard behaviour required for the snap.
Thanks @alexmurray. I’ve created a PR for that. I’m not familiar with go language, but it seems that the PR is not hard.
Do you know how long it would take to back-port this change in the stable release? I’m in the end of my sprint and depending on how long it will take, I’ll add the snap as a resource to the charm.
Looking forward to your review.
+1 from me too for auto-connect of mount-observe for opensearch, given that the snap requires read access to file-system stats/attributes to function.
+2 votes for auto-connect of mount-observe for opensearch. This is now live. Regarding timing for having the change to system-observe - this would be a question for @mvo and the snapd team.
