Apologies for the slow response and also for top-posting. 1. I did review the NetApp situation because to be honest, I was horrified to learn that the Cinder community had allowed this, and the code link to netapp/utils.py#L570 is not very enlightening. The key places to look are out in the netapp drivers where the EMS log messages are being sent. A NetApp driver maintainer should verify this, but it looks to me like what's going on is a looping task is created that sends info from the cinder driver to the NetApp storage backend the driver is connected to. See, for example, send_ems_log_message() and _get_ems_log_destination_vserver() in netapp/dataontap/client/client_cmode.py So from what I can tell (and, again, I'd like a NetApp driver maintainer to confirm this), the info being sent from cinder to the backend is under the control of the cloud operator, and NetApp support people would need appropriate credentials from the cloud operator to access it on the storage back end. I don't think there's a problem with this from a privacy point of view. 2. My understanding of "call home" technology is that the software reports back to the vendor. This doesn't seem to be what NetApp is doing--the customer has control of the data and can decide whether or not to release it to NetApp. My point is that as far as I can tell, we do *not* have a precedent in cinder for allowing "call home" from our drivers. 3. As far as your patch goes, the commit message says:
[Storage Virtualize family] Added SVC callhome plugin registration for Cinder driver
Enabling callhome feature on the IBM Spectrum Virtualize Family (SVf) driver. By default, callhome will be enabled. To disable it, specify `callhome = disable` in the configuration. This enhancement allows collection of the OS version, Cinder manager version, and usage details of PBHA and replication features.
The key issue for me is "this enhancement allows collection" ... collection by whom, and where it is stored? If it's calling home to the vendor, then I agree with the comment Kees made elsewhere in this thread that it should be off by default. And if it's not calling home to the vendor, then please make that clear in the commit message (and consider calling the feature something other than "call home"!). cheers, brian On 7/24/25 1:34 AM, Jon Bernard wrote:
On Jul 17, Vivek Pandey <Vivek.Pandey11@ibm.com> wrote:
Hi Joe/ Brian,
Since we didn’t get a chance to discuss the patch [IBM SVf driver] Adding support for callhome plugin, we can continue the conversation here. Patch : https://review.opendev.org/c/openstack/cinder/+/951829.
We need callhome enabled as default for which we have introduced a parameter “callhome” in cinder.conf. This feature is to fecth the os_version, cinder-manage version and ispbhaenabled.
Note: We are not fetching any customer’s sensitive data.
Please let me know if you’ve had a chance to review NetApp’s ActiveIQ implementation. Netapp’s ActiveIQ code ref : https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netapp...
As we have discussed during the 9th July cinder call, Anoop from NetApp confirmed that they are enabling it by default and EMS details are being captured from the logs. Based on that, do you think we can align or extend our current IBM callhome implementation (from the patch above) to follow a similar approach?
I think this question would benefit from a wider audience. As I said in the code review [1], I don't think our drivers should have default enabled phone-home functionality in the upstream repository. A vendor is certainly free to change this in a packaged version, but I think our defaults confer information about how we think about our users and I tend to want to put them first. I'm happy to hear other opinions on this. I did bring this up with the TC on IRC when it came up, it may be that we have a better consensus on such things across projects. I'm eager to hear other thoughts.
1. https://review.opendev.org/c/openstack/cinder/+/951829/comment/c6b5df57_4086...