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://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://urldefense.proofpoint.com/v2/url?u=https-3A__review.opendev.org_c_openstack_cinder_-2B_951829&d=DwIDaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=XY8e94ucngd0daokROeuV3aCyePOGZdhziXYiph3s6Y&m=0kd7gkKkY1Pwlhq348IeOL6J1FcMXRqEBf0Q6brljZoY8beP-FycSXX7LGWYmt4D&s=SzLAlIK8EJNYSNX7WGwd1S7vyyM4PPbdvkO4k2TVRx0&e=
> .
> >>
> >> 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://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=0kd7gkKkY1Pwlhq348IeOL6J1FcMXRqEBf0Q6brljZoY8beP-FycSXX7LGWYmt4D&s=yBHHbFKMccS-fWPKwOCckrt3YaRHVTWKsweTXjDY8HQ&e=
>
>
> >>
> >> 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://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=0kd7gkKkY1Pwlhq348IeOL6J1FcMXRqEBf0Q6brljZoY8beP-FycSXX7LGWYmt4D&s=zoQxMhRslc8TzQnp9uLGR2WLqR4sOzegx7bQSje4qEY&e=
>
>
> >
>