As part of the BootStack DevOps team, I would like to request approval for classic confinement for the python package called prometheus-hardware-exporter.
The BootStack DevOps team will like to rewrite the existing charm-hw-health using the Operator framework, and provide native support for COS-lite. To achieve that, we split our implementation into a charm (still in progress) + an prometheus exporter (core features are completed).
The Prometheus exporter will need to run some vendor provided 3rd party tools to collect the metrics about the RAID cards / IPMI / NVME / … on the host machine. And then the charm will install the exporter (snap) as a service offering a HTTP scrape endpoint, and also act as a medium to install the 3rd party tool and configure the exporter (snap).
However, the problem is that the 3rd party tools need direct access to the host machine in order to collect the metrics about the hardware. And we have tried running snappy-debug to find out what plugs are required for one of the 3rd party tool (storcli) but we found out that the tool is somehow using mknod internally, and mknod is generally not allow in strictly confined snap. And considering that most of the 3rd party tools used in this package are system administrative tools that requires direct access to the hardware on the host, so we would like to request for classic confinement.
Apologies for the few days it’s taken to get to this request. Per the process for reviewing classic confinement snaps, are you able to suggest if prometheus-hardware-exporter fits into any of the supported categories for classic confinement?
The purpose is this snap is to generate the output of hardware metrics for monitoring. Currently we don’t see any supported categories for this purpose. I think that is a missing part of the categories, right?
I tend to agree, the purpose doesn’t fit within any of the existing supported categories for classic confinement. Rather than make exceptions and grow the list of categories, the approach we take is to look at how we might be able to improve the snapd interfaces to support as many use cases as possible under strict confinement due to the security and portability benefits that provides.
If you are able to provide some more detailed information about the 3rd party tools, the way the snap is being packaged (supplying those tools within the snap?), and the various snappy-debug logs then perhaps we can start to look at whether any interface changes or new interfaces might be appropriate to support this.
I understand your concerns. I also don’t want to simply request an extra supported category just because we think it’s good / useful.
I want to clarify a bit for the 3rd party tools. We don’t package them into our snap, and we can’t because of legal issues (we can’t redistribute them in any form). In our snap, we simply assumed that the 3rd party tools exist (e.g. in the hosts, or SNAP_COMMON), and we call them via Python’s subprocess, and get the output we need or handle the error if the tools are not installed. In some sense, it’s a bit dangerous because we rely on the user to install the correct 3rd party tools.
For snappy-debug log, we have, so far, tested with one of the 3rd party tools storcli, and added some interfaces suggested by snappy-debug. In the end, we found that it’s making mknod calls, and we cannot find any interface to make it work.
Since this is not possible, how difficult would be for you team to implement what storcli provides in the prometheus-hardware-exporter snap and remove this 3rd party dependency?
Please note that allowing classic confinement grants device ownership to the snap, so it is a very sensitive request. In this case, the need is related to a 3rd party tool not properly operating which is a) not only an unsupported category: “dependent software only available on host”, but b) I see its purpose is to help collect hardware metrics for which we have several interfaces under strict confinement.
I will say it’s not even possible. StorCLI is publish by Broadcom and it’s not a open source project.
And StorCLI is just one of the 3rd party tool we cover, which we use to monitor the RAID card device from Broadcom. And we would like to cover all the tools publish by different vendors.
It’s unfortunately that the hardware vendors’ usually release their exclusive tool like this and it seems not fit to our policy for snap.
Most of the vendors’ 3rd party tool are not open source and they are not allow to re-published.
They are exclusive, you need to use the tool to connect to the device.
Of course, they need sudo permission.
So the problem seems be clear, if we want to have a snap which can export the hardware metrics, what can we do?
After a conversation with the snapd architect (pedronis) about this today, we believe the best approach will be the creation a new interface to support this particular use case. I will message you separately to discuss the way forward.
