Hi, I noticed the following BP has been merged recently: https://blueprints.launchpad.net/cinder/+spec/filtering-weighing-with-driver-supplied-functions i have read the related spec(http://git.openstack.org/cgit/openstack/cinder-specs/tree/specs/kilo/filtering-weighing-with-driver-supplied-functions.rst) and have got some questions.
For my understanding, this BP brought two benefits: 1) different admins can make various configurations on filtering/weighing (by editing equation in cinder.conf) to meet their various requirement; the equation way itself is much more flexible than single capability scheduling. 2) different backend drivers can take vendor specific evaluation; The BP seems focus more on the second target: letting drivers do evaluation by themselves. In the spec "editing equation in cinder.conf" is just an example of driver implementation, "it is up to the driver to determine how to generate the equations...Some choices a driver has are to use values defined in cinder.conf, hard-code the values in the driver or not implement the properties at all". But I think it is also a fact that a lot of devices have common capabilities/attributes(even thin-provisionning can take as a common attribute today), so can we make the "editing equation in cinder.conf" a base/common implementation to this new scheduler? Which means: 1) this new scheduler has a built-in implementation of filter/goodness funtion; 2) drivers can supply their own functions as they do now; If a driver do not supply one, built-in function will work; Another question: Can we make different volume-types associated with different evaluation rule (means different filter/goodness function pair)? I think this is also very useful. Thanks.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
