[openstack-dev] [cinder]The backend-group concept in Cinder

chen ying chenyingkof at outlook.com
Tue Jun 14 09:15:04 UTC 2016


Hi Duncan Thomas,
        Does you means we can create a volume type include list of backend names(such as: backend_name="<in> name1 name2 name3 name4"), so when we create a volume, we can use the volume type to choose  one backend from these list of backend names(name1,name2,name3,name4)?
But in this way, we cannot show the backends obviously capabilities to users(such as: performance, ssd, spinning-rust etc).



________________________________
发件人: Duncan Thomas <duncan.thomas at gmail.com>
发送时间: 2016年6月14日 8:03
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [cinder]The backend-group concept in Cinder

As long as each backend has a unique name, you can key the type to a list of backend names if there's no useful capabilities to key off. No restart required.

On 14 June 2016 at 10:16, chen ying <chenyingkof at outlook.com<mailto:chenyingkof at outlook.com>> wrote:

Hi John,



    User case 1:
          The  backends in backend-group-1 have SSD disk, more memory . The backend-group-1 can provide higher performance to user.
          The other  backends  in  backend-group-2 have HHD disk, more capacity. The backend-group-2 can provide more storage space to user .

Not sure, but we sort of do some of this already via the filter scheduler.  An Admin can define various types (they may be set up based on performance, ssd, spinning-rust etc).  Those types are then given arbitrary definitions via a type (again details hidden from end user) and he/she can create volumes of a specific type.



Yes,  An Admin can arbitrary define various types and he/she can create volumes of a specific type. But we need to restart our cinder driver after define various types in each driver(If the driver cannot report capabilities by itself). It will not easy to manage for Admin.

Does Admin could use the concept of dynamically adding/removing backends to backend-group. In this way, we not need to modify backend configure file(such as: report a capabilities of ssd, spinning-rust etc).We can arbitrary define various types for backend-group, and also he/she can create volumes of a specific type(from backend-group type).

So for example I could say "I want these backends with capability XYZ", and many of backends from different vendors. How to manage these backends by Administrator?

Currently:

1.        Admin need modify backend configure file, let the backend report capability XYZ to filter scheduler.

2.        Restart the volume service, make the capability valid

3.        Create volume type(test_type) with capability XYZ.

4.        he/she can create volumes of a specific type(test_type)

       Now we expect:

1.        Admin add backend to backend-group

2.        Create volume type(test_type) with capability XYZ, use frefix(group or something else (group: capability = XYZ)) to distinguish between the backend capability and the backend-group capability.

3.        he/she can create volumes of a specific type(test_type)


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
--
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160614/d775291b/attachment.html>


More information about the OpenStack-dev mailing list