On 12/11, Harsh Ailani wrote:
Hi Gorka,
I tried to work with the ‘provider_id’ field and though it worked for clone operation, the demerit is that now I need to use the ‘provider_id’ field for all the volume operations that can be performed on the cloned-volumes.
Instead of that, we came up with a smaller change that would render the change for all the volume operations.
Below is the change that we came up with but we would like to know from you and the community if this is acceptable:
File name: cinder/cinder/objects/volume.py
Code change: @property def name(self): if self.provider_id: return self.provider_id else: return CONF.volume_name_template % self.name_id
Please let us know if this change would be acceptable.
Hi, Unfortunately that is not an acceptable change, not because it is not a good solution to your problem, but because it could potentially break other drivers that are using the `provider_id` field. The solution is to make changes in your driver. This can take many forms: - A decorator on all methods that receive a volume and wraps it in a class that has a different `name` property. - Create a method `_get_name` in your driver and use it to do the same thing as the code you wrote above. - Just use more compact code to get the real value to use. Something like: vol.provider_id or vol.name You can use that anywhere you need to: self._my_method_on_volume(vol.provider_id or vol.name) name = vol.provider_id or vol.name I'm sure there are many other possibilities. Changing the behavior of a base object is a risky thing to do, and it requires very thorough and careful analysis of existing code in the repository. Cheers, Gorka.
Thanks and Regards, Harsh Ailani
Openstack Developer - Flashsystem Mobile : +91-9988410497
IBM
From: Harsh Ailani <harsh.ailani@ibm.com> Date: Thursday, 26 September 2024 at 12:49 PM To: Gorka Eguileor <geguileo@redhat.com> Cc: openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Subject: [EXTERNAL] RE: OpenStack Cinder - Volume-ID in cinder DB Hi Gorka, Thankyou so much for the insight ! This would really solve my problem. I will try this out and get back to you shortly. Thanks and Regards, Harsh Ailani From: Gorka Eguileor <geguileo@ redhat. com> Date: Tuesday, 24 September 2024
Hi Gorka,
Thankyou so much for the insight !
This would really solve my problem. I will try this out and get back to you shortly.
Thanks and Regards, Harsh Ailani
From: Gorka Eguileor <geguileo@redhat.com> Date: Tuesday, 24 September 2024 at 5:26 PM To: Harsh Ailani <harsh.ailani@ibm.com> Cc: openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Subject: [EXTERNAL] Re: OpenStack Cinder - Volume-ID in cinder DB On 19/09, Harsh Ailani wrote:
Hello contributors,
I am working on clone operation for a volumegroup and in that the volume ID auto-generated by OpenStack is not the one with which the clone volumes are being created on my IBM storage backend. This is as per design that IBM Storage backend will take the source-volume ID in the source-volumegroup and add a suffix to it while cloning.
Now since there is a mismatch in the IDs between cinder and storage backend, because of which I am unable to perform any volume operations on this cloned volume. So, I was wondering if I can change the volume ID in cinder DB?
I know that it’s a unique key and there is a limit of 36 characters for this field in cinder DB, but since I cannot change the volume in storage backend, I wanted to check if there is a way I can alter the volume ID in cinder DB?
Kindly share your thoughts/suggestions on this matter.
Thanks and Regards, Harsh Ailani
Hi,
Having different references in Cinder and in the storage array is supported by Cinder and its drivers.
Cinder drivers can store a driver specific ID in the `provider_id` field of the volume [1], which is considerably larger (255 chars).
Your driver just needs to return the values of the `provider_id` in a dictionary of the `create_volume`, `create_cloned_volume`, and other similar methods that create or move volumes.
You can find some examples in other existing cinder drivers that also use this field, such as Pure, SolidFire, PowerFlex, Unity, SC, PowerStore, etc.
Cheers, Gorka.