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
