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 <[email protected]> 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 <[email protected]> > *发送时间:* 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 <[email protected]> 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: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > -- > Duncan Thomas > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
