[openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?
liuxinguo at huawei.com
Fri Mar 25 01:44:45 UTC 2016
My basic idea is that, when we need to migrate a volume from my (vendor of) storage array to another backend (storage array), we will firstly call the other backend's create_volume() to create a volume on the other backend,
and then we will take my backend (storage array) as a "host" and attach other backend's volume to our backend (storage array). And then we can migrate the volume from our storage array to other storage array directly and very efficiently.
And at last when the migration finished, we call the other backend's terminate_connection() to detach the volume from our storage array.
Of course, the precondition is that our backend array is connected (can copy data) to other backend array so we can migrate volume directly between them.
发件人: Jon Bernard [mailto:jbernard at tuxion.com]
发送时间: 2016年3月23日 4:44
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?
* liuxinguo <liuxinguo at huawei.com> wrote:
> Hi Cinder team,
> We are going to implement storage-assisted volume migrate in our
> driver between different backend storage array or even different array
> of different vendors. This is really high-efficiency than the
> host-copy migration between different array of different vendors.
Could you elaborate more on this? During a volume migration operation we give the driver an opportunity to more-intelligently relocate the volume's data. This is done through the migrate_volume() method defined in the driver itself. If this method exists, it will be called before falling back to a byte-for-byte copy approach - and if it succeeds the volume is considered migrated and the operation returns.
Is this what you were looking for, or did you have something different in mind?
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev