Open Stack

You can define several backends with the same volume_backend_name and call
that a group. For example:
[groupA-be1]
volume_backend_name=fast-ssd

[groupA-be2]
volume_backend_name=fast-ssd

[groupB-be3]
volume_backend_name=slow-disk

So, no matter what storage is behind every backend, it will be filtered
 based on the backend_name (and the other capabilities each backend
reports). If you don't want to restart the volume service to each backend
you add. You can add another instance of cinder-volume, even in the same
controller. The scheduler will know how to handle the new ones.

Erlon


On Tue, Jun 14, 2016 at 6:15 AM, chen ying <chenyingkof at outlook.com> wrote:

> 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> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> --
> Duncan Thomas
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160615/2444183d/attachment.html>