[openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?

John Griffith john.griffith8 at gmail.com
Fri Mar 18 14:08:17 UTC 2016


On Thu, Mar 17, 2016 at 10:05 PM, 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.
>
>
>
> To implement this, we need to call other backend’s method like
> create_volume() or initialize_connection(). We can call them like the
> cinder/volume/manage.py:
>
>
>
>         rpcapi.create_volume(ctxt, new_volume, host[*'host'*],
>
>                              None, None, allow_reschedule=False)
>
>
>
> or
>
>         conn = rpcapi.initialize_connection(ctxt, volume, properties)
>
>
>
> And my question is: Does the OpenStack community(or Cinder team) allow
> driver to call rpcapi in order to call other driver’s method like
> create_volume() or initialize_connection()?
>
>
>
>
>
> Thanks for any input!
>
> --
>
> Wilson Liu
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ​Hi Wilson,

We don't have a direct version of the model you describe in place
currently.  We do have something similar by coordinating through the api
and scheduler layers, there's even some existing code in the migrate code
that does some similar things in manager.py.

It would be good to see if you could leverage some of the design that's
already in place.  I don't know that there should be an objection to having
a driver call another driver but it really depends on how in depth it ends
up being and how all the details around context and quota are dealt with.

I'd be curious to see what you've got going.  Might be something that helps
make the migrate code we already have better?

Thanks,
John​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160318/b01bbe75/attachment.html>


More information about the OpenStack-dev mailing list