Sounds like a reasonable optimization, but may not always be possible. Take, for example, the ceph backend. For other backends that are appliances, they would have to be able to implement a ceph client that matches the version of the ceph servers in use. That might be very difficult to support.
So maybe allow it, but have some automatic fall back mechanism if it fails? Thanks, Kevin ________________________________________ From: liuxinguo [liuxin...@huawei.com] Sent: Thursday, March 24, 2016 6:44 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Zhangli (ISSP); Luozhen Subject: Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method? Hi Jon, 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. -- Wilson Liu -----邮件原件----- 发件人: Jon Bernard [mailto:jbern...@tuxion.com] 发送时间: 2016年3月23日 4:44 收件人: OpenStack Development Mailing List (not for usage questions) 抄送: Luozhen 主题: Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method? * liuxinguo <liuxin...@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? -- Jon __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
