[cinder] IBM SVf driver callhome
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? Thanks, Vivek
Gentle reminder… !!! Thanks, Vivek From: Vivek Pandey <Vivek.Pandey11@ibm.com> Date: Thursday, 17 July 2025 at 12:11 PM To: openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Subject: [EXTERNAL] [cinder] IBM SVf driver callhome 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 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<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/utils.py#L570<https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netapp/utils.py#L570 > 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? Thanks, Vivek
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... -- Jon
Hi Jon, On 24-07-2025 07:34, Jon Bernard wrote:
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.
You're absolutely right: phone-home mustn't be a default, or obliged from a functionality perspective. Privacy minded users would only think it's suspicious (I would). Cheers, Kees
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...
Hi Brian, We would like to clarify the behaviour of the Cinder plugin and its metadata collection mechanism. Upon registration of the Cinder plugin, we retrieve metadata such as the OS version, PBHA status, Cinder manage version, replication status, and deployment type. This metadata is displayed locally on the Flash System through the lsplugin CLI, as shown in the attached screenshot. It’s important to note that this metadata comprises only basic system details and does not include any sensitive configurations or data. [cid:image002.png@01DC06EC.99CD4F50] Please be aware that plugin metadata will not be transmitted to IBM unless the customer explicitly enables Call Home on the backend. The Call Home feature must be configured by the user in order for any plugin or system data to be sent externally. This ensures that customers retain full control over data sharing. Unless Call Home is enabled, we do not receive any system information. Furthermore, it is not possible to enable Call Home via the Cinder interface. The configuration of Call Home must be handled separately by the customer. [cid:image001.png@01DC06EC.65FFE570] Thanks, Vivek From: Brian Rosmaita <rosmaita.fossdev@gmail.com> Date: Wednesday, 30 July 2025 at 8:50 PM To: openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Subject: [EXTERNAL] Re: [cinder] IBM SVf driver callhome 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...
On 06/08/2025 11:47, Vivek Pandey wrote:
Hi Brian,
We would like to clarify the behaviour of the Cinder plugin and its metadata collection mechanism.
Upon registration of the Cinder plugin, we retrieve metadata such as the OS version, PBHA status, Cinder manage version, replication status, and deployment type. This metadata is displayed locally on the Flash System through the lsplugin CLI, as shown in the attached screenshot. It’s important to note that this metadata comprises only basic system details and does not include any sensitive configurations or data.
the version info related ot the os cinder version and kernel/patch version is generally consider sensitive in that it can be used to check for known security exploits that may be unpatcted. so depending on where this is displaced some woudl coniser this sensitive. the uniqe_key may also have gdpr implciaitons. i dont think any in tree plugin shoudl have call home fucntionaltiy enabel by default and likely it shoudl not live in tree at all. i.e. it should be an optional out of tree plugin or optional fucntionablity that need an expiclty opt in. just my 2 cents
Please be aware that plugin metadata will not be transmitted to IBM unless the customer explicitly enables Call Home on the backend. The Call Home feature must be configured by the user in order for any plugin or system data to be sent externally. This ensures that customers retain full control over data sharing. Unless Call Home is enabled, we do not receive any system information.
Furthermore, it is not possible to enable Call Home via the Cinder interface. The configuration of Call Home must be handled separately by the customer.
Thanks, Vivek
*From: *Brian Rosmaita <rosmaita.fossdev@gmail.com> *Date: *Wednesday, 30 July 2025 at 8:50 PM *To: *openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> *Subject: *[EXTERNAL] Re: [cinder] IBM SVf driver callhome
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://urldefense.proofpoint.com/v2/url?u=https-3A__review.opendev.org_c_openstack_cinder_-2B_951829&d=DwIDaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=XY8e94ucngd0daokROeuV3aCyePOGZdhziXYiph3s6Y&m=qyfxFU9RoovkyJtAfBGbtFMTRsj0voLLZPLvK40sfWghrn_-TZ2lm-h0AzGLFO2w&s=0MdOYBLMw2Fyh0LP82v_J4SmF01d8q7JHvuiVqhx-9c&e= <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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_cinder_blob_master_cinder_volume_drivers_netapp_utils.py-23L570&d=DwIDaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=XY8e94ucngd0daokROeuV3aCyePOGZdhziXYiph3s6Y&m=qyfxFU9RoovkyJtAfBGbtFMTRsj0voLLZPLvK40sfWghrn_-TZ2lm-h0AzGLFO2w&s=BKQ5cjYn31YoJ6X_t_2JMwkBIBpoySXVZJgXd2-kNdE&e= <https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netapp/utils.py#L570>
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://urldefense.proofpoint.com/v2/url?u=https-3A__review.opendev.org_c_openstack_cinder_-2B_951829_comment_c6b5df57-5F40862bcc_&d=DwIDaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=XY8e94ucngd0daokROeuV3aCyePOGZdhziXYiph3s6Y&m=qyfxFU9RoovkyJtAfBGbtFMTRsj0voLLZPLvK40sfWghrn_-TZ2lm-h0AzGLFO2w&s=JtJWU1MiGZnWsFoX0eaxYaDIMtOaaw1rLg3DYcsj-uY&e= <https://review.opendev.org/c/openstack/cinder/+/951829/comment/c6b5df57_40862bcc/>
Hi Sean/Brian, We were previously capturing the OS release information to identify the OpenStack distribution. However, as Sean pointed out, collecting OS release data along with the host UUID is considered sensitive and may have GDPR implications. After internal discussions, the team has agreed to proceed without capturing the OS release data in the metadata. We will continue capturing the UUID to help identify duplicate plugin registration requests from the same host. As mentioned in the thread, it is not possible to enable Call Home via the Cinder interface. This configuration must be managed separately by the customer. We are updating the patch set to reflect this approach. Please proceed with the patch review. Thanks, Vivek From: Sean Mooney <smooney@redhat.com> Date: Wednesday, 6 August 2025 at 6:36 PM To: Vivek Pandey <Vivek.Pandey11@ibm.com>, Brian Rosmaita <rosmaita.fossdev@gmail.com>, openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Cc: Sandip Rajbanshi <Sandip.Rajbanshi@ibm.com>, Subhojit Roy <subhojit.roy@in.ibm.com> Subject: [EXTERNAL] Re: [cinder] IBM SVf driver callhome On 06/08/2025 11:47, Vivek Pandey wrote:
Hi Brian,
We would like to clarify the behaviour of the Cinder plugin and its metadata collection mechanism.
Upon registration of the Cinder plugin, we retrieve metadata such as the OS version, PBHA status, Cinder manage version, replication status, and deployment type. This metadata is displayed locally on the Flash System through the lsplugin CLI, as shown in the attached screenshot. It’s important to note that this metadata comprises only basic system details and does not include any sensitive configurations or data.
the version info related ot the os cinder version and kernel/patch version is generally consider sensitive in that it can be used to check for known security exploits that may be unpatcted. so depending on where this is displaced some woudl coniser this sensitive. the uniqe_key may also have gdpr implciaitons. i dont think any in tree plugin shoudl have call home fucntionaltiy enabel by default and likely it shoudl not live in tree at all. i.e. it should be an optional out of tree plugin or optional fucntionablity that need an expiclty opt in. just my 2 cents
Please be aware that plugin metadata will not be transmitted to IBM unless the customer explicitly enables Call Home on the backend. The Call Home feature must be configured by the user in order for any plugin or system data to be sent externally. This ensures that customers retain full control over data sharing. Unless Call Home is enabled, we do not receive any system information.
Furthermore, it is not possible to enable Call Home via the Cinder interface. The configuration of Call Home must be handled separately by the customer.
Thanks, Vivek
*From: *Brian Rosmaita <rosmaita.fossdev@gmail.com> *Date: *Wednesday, 30 July 2025 at 8:50 PM *To: *openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> *Subject: *[EXTERNAL] Re: [cinder] IBM SVf driver callhome
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 <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... <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... <https://review.opendev.org/c/openstack/cinder/+/951829/comment/c6b5df57_4086... >
Hi Jon, We have found a means to ensure that the register plugin is not turned on by default. What we can do is to keep it disabled by default in the cinder.conf file. Upon initialisation of the Cinder driver, we will check with the IBM Storage to which it is connected and based on the configuration setting already selected by the FlashSystem administrator with respect to Callhome i.e. it is either enabled or disabled, we turn on plugin registration and if the admin hasn't enabled CallHome for the IBM storage, then we don't turn on plugin registration. This should be acceptable to the admin because they have already agreed to enable CallHome support for FlashSystems for better support purposes and hence turning on plugin registration should be fine. * If CallHome is enabled, the plugin will register automatically and log an INFO message indicating that telemetry data will be sent to the vendor. * If CallHome is disabled, registration will be skipped and an INFO message will clarify that CallHome is turned off. * Should CallHome be enabled later, a WARNING will be logged to inform the operator that a driver restart is required to register the plugin. Here is the output of the CLI that displays whether CallHome has been turned on in FlashSystems or not: "[09:53:30] Ansible-FS5200-2-n2:~ # lscloudcallhome status enabled connection active error_sequence_number last_success 250910095534 last_failure si_tenant_id apikey_configured no [09:57:29] Ansible-FS5200-2-n2:~ # " Thanks, Vivek From: Vivek Pandey <Vivek.Pandey11@ibm.com> Date: Wednesday, 13 August 2025 at 12:08 PM To: Sean Mooney <smooney@redhat.com>, Brian Rosmaita <rosmaita.fossdev@gmail.com>, openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Cc: Sandip Rajbanshi <Sandip.Rajbanshi@ibm.com>, Subhojit Roy <subhojit.roy@in.ibm.com> Subject: [EXTERNAL] RE: [cinder] IBM SVf driver callhome Hi Sean/Brian, We were previously capturing the OS release information to identify the OpenStack distribution. However, as Sean pointed out, collecting OS release data along with the host UUID is considered sensitive and may have GDPR implications. Hi Sean/Brian, We were previously capturing the OS release information to identify the OpenStack distribution. However, as Sean pointed out, collecting OS release data along with the host UUID is considered sensitive and may have GDPR implications. After internal discussions, the team has agreed to proceed without capturing the OS release data in the metadata. We will continue capturing the UUID to help identify duplicate plugin registration requests from the same host. As mentioned in the thread, it is not possible to enable Call Home via the Cinder interface. This configuration must be managed separately by the customer. We are updating the patch set to reflect this approach. Please proceed with the patch review. Thanks, Vivek From: Sean Mooney <smooney@redhat.com> Date: Wednesday, 6 August 2025 at 6:36 PM To: Vivek Pandey <Vivek.Pandey11@ibm.com>, Brian Rosmaita <rosmaita.fossdev@gmail.com>, openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Cc: Sandip Rajbanshi <Sandip.Rajbanshi@ibm.com>, Subhojit Roy <subhojit.roy@in.ibm.com> Subject: [EXTERNAL] Re: [cinder] IBM SVf driver callhome On 06/08/2025 11:47, Vivek Pandey wrote:
Hi Brian,
We would like to clarify the behaviour of the Cinder plugin and its metadata collection mechanism.
Upon registration of the Cinder plugin, we retrieve metadata such as the OS version, PBHA status, Cinder manage version, replication status, and deployment type. This metadata is displayed locally on the Flash System through the lsplugin CLI, as shown in the attached screenshot. It’s important to note that this metadata comprises only basic system details and does not include any sensitive configurations or data.
the version info related ot the os cinder version and kernel/patch version is generally consider sensitive in that it can be used to check for known security exploits that may be unpatcted. so depending on where this is displaced some woudl coniser this sensitive. the uniqe_key may also have gdpr implciaitons. i dont think any in tree plugin shoudl have call home fucntionaltiy enabel by default and likely it shoudl not live in tree at all. i.e. it should be an optional out of tree plugin or optional fucntionablity that need an expiclty opt in. just my 2 cents
Please be aware that plugin metadata will not be transmitted to IBM unless the customer explicitly enables Call Home on the backend. The Call Home feature must be configured by the user in order for any plugin or system data to be sent externally. This ensures that customers retain full control over data sharing. Unless Call Home is enabled, we do not receive any system information.
Furthermore, it is not possible to enable Call Home via the Cinder interface. The configuration of Call Home must be handled separately by the customer.
Thanks, Vivek
*From: *Brian Rosmaita <rosmaita.fossdev@gmail.com> *Date: *Wednesday, 30 July 2025 at 8:50 PM *To: *openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> *Subject: *[EXTERNAL] Re: [cinder] IBM SVf driver callhome
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 <https://review.opendev.org/c/openstack/cinder/+/951829 > <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... <https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netapp... > <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... <https://review.opendev.org/c/openstack/cinder/+/951829/comment/c6b5df57_4086... > <https://review.opendev.org/c/openstack/cinder/+/951829/comment/c6b5df57_4086... >
Hi Jon/Brian, I wanted to bring one additional point to your attention as a follow-up. It’s important to consider that other storage providers who consistently collect telemetry data are better positioned to deliver higher-quality features and implement faster improvements. By contrast, disabling our plugin by default puts us at a disadvantage in terms of both visibility and responsiveness. Relying solely on customers to enable CallHome on the backend—with the expectation that it will automatically ensure plugin registration—introduces a real risk of misconfiguration or oversight. Moreover, requiring an additional configuration parameter just to enable registration adds unnecessary overhead and may not always reflect the operator's true intent. Keeping the plugin enabled by default helps avoid these gaps, ensures consistent data collection, and better enables our support and development teams to serve our users effectively. Thanks, Vivek From: Vivek Pandey <Vivek.Pandey11@ibm.com> Date: Wednesday, 10 September 2025 at 3:55 PM To: Sean Mooney <smooney@redhat.com>, Brian Rosmaita <rosmaita.fossdev@gmail.com>, openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Cc: Sandip Rajbanshi <Sandip.Rajbanshi@ibm.com>, Subhojit Roy <subhojit.roy@in.ibm.com> Subject: Re: [EXTERNAL] RE: [cinder] IBM SVf driver callhome Hi Jon, We have found a means to ensure that the register plugin is not turned on by default. What we can do is to keep it disabled by default in the cinder.conf file. Upon initialisation of the Cinder driver, we will check with the IBM Storage to which it is connected and based on the configuration setting already selected by the FlashSystem administrator with respect to Callhome i.e. it is either enabled or disabled, we turn on plugin registration and if the admin hasn't enabled CallHome for the IBM storage, then we don't turn on plugin registration. This should be acceptable to the admin because they have already agreed to enable CallHome support for FlashSystems for better support purposes and hence turning on plugin registration should be fine. * If CallHome is enabled, the plugin will register automatically and log an INFO message indicating that telemetry data will be sent to the vendor. * If CallHome is disabled, registration will be skipped and an INFO message will clarify that CallHome is turned off. * Should CallHome be enabled later, a WARNING will be logged to inform the operator that a driver restart is required to register the plugin. Here is the output of the CLI that displays whether CallHome has been turned on in FlashSystems or not: "[09:53:30] Ansible-FS5200-2-n2:~ # lscloudcallhome status enabled connection active error_sequence_number last_success 250910095534 last_failure si_tenant_id apikey_configured no [09:57:29] Ansible-FS5200-2-n2:~ # " Thanks, Vivek From: Vivek Pandey <Vivek.Pandey11@ibm.com> Date: Wednesday, 13 August 2025 at 12:08 PM To: Sean Mooney <smooney@redhat.com>, Brian Rosmaita <rosmaita.fossdev@gmail.com>, openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Cc: Sandip Rajbanshi <Sandip.Rajbanshi@ibm.com>, Subhojit Roy <subhojit.roy@in.ibm.com> Subject: [EXTERNAL] RE: [cinder] IBM SVf driver callhome Hi Sean/Brian, We were previously capturing the OS release information to identify the OpenStack distribution. However, as Sean pointed out, collecting OS release data along with the host UUID is considered sensitive and may have GDPR implications. Hi Sean/Brian, We were previously capturing the OS release information to identify the OpenStack distribution. However, as Sean pointed out, collecting OS release data along with the host UUID is considered sensitive and may have GDPR implications. After internal discussions, the team has agreed to proceed without capturing the OS release data in the metadata. We will continue capturing the UUID to help identify duplicate plugin registration requests from the same host. As mentioned in the thread, it is not possible to enable Call Home via the Cinder interface. This configuration must be managed separately by the customer. We are updating the patch set to reflect this approach. Please proceed with the patch review. Thanks, Vivek From: Sean Mooney <smooney@redhat.com> Date: Wednesday, 6 August 2025 at 6:36 PM To: Vivek Pandey <Vivek.Pandey11@ibm.com>, Brian Rosmaita <rosmaita.fossdev@gmail.com>, openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Cc: Sandip Rajbanshi <Sandip.Rajbanshi@ibm.com>, Subhojit Roy <subhojit.roy@in.ibm.com> Subject: [EXTERNAL] Re: [cinder] IBM SVf driver callhome On 06/08/2025 11:47, Vivek Pandey wrote:
Hi Brian,
We would like to clarify the behaviour of the Cinder plugin and its metadata collection mechanism.
Upon registration of the Cinder plugin, we retrieve metadata such as the OS version, PBHA status, Cinder manage version, replication status, and deployment type. This metadata is displayed locally on the Flash System through the lsplugin CLI, as shown in the attached screenshot. It’s important to note that this metadata comprises only basic system details and does not include any sensitive configurations or data.
the version info related ot the os cinder version and kernel/patch version is generally consider sensitive in that it can be used to check for known security exploits that may be unpatcted. so depending on where this is displaced some woudl coniser this sensitive. the uniqe_key may also have gdpr implciaitons. i dont think any in tree plugin shoudl have call home fucntionaltiy enabel by default and likely it shoudl not live in tree at all. i.e. it should be an optional out of tree plugin or optional fucntionablity that need an expiclty opt in. just my 2 cents
Please be aware that plugin metadata will not be transmitted to IBM unless the customer explicitly enables Call Home on the backend. The Call Home feature must be configured by the user in order for any plugin or system data to be sent externally. This ensures that customers retain full control over data sharing. Unless Call Home is enabled, we do not receive any system information.
Furthermore, it is not possible to enable Call Home via the Cinder interface. The configuration of Call Home must be handled separately by the customer.
Thanks, Vivek
*From: *Brian Rosmaita <rosmaita.fossdev@gmail.com> *Date: *Wednesday, 30 July 2025 at 8:50 PM *To: *openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> *Subject: *[EXTERNAL] Re: [cinder] IBM SVf driver callhome
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 <https://review.opendev.org/c/openstack/cinder/+/951829 > <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... <https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netapp... > <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... <https://review.opendev.org/c/openstack/cinder/+/951829/comment/c6b5df57_4086... > <https://review.opendev.org/c/openstack/cinder/+/951829/comment/c6b5df57_4086... >
participants (5)
-
Brian Rosmaita
-
Jon Bernard
-
Kees Meijs | Nefos
-
Sean Mooney
-
Vivek Pandey