Hi Thanks for looking at / thinking about this. So the idea was (I started this whole thing rolling long ago after a rather heated discussion with a very bright chap from Redhat):
1) Driver authors tend, in my experience, to know more than admins, so drivers should be able (where useful) to be able to set a default value to either filter expression or weighting expression 2) Admins definitely need to be able to over-ride this if desired via cinder.conf I thing it is fairly easy (and beneficial) to go through the in-tree drivers and add the conf value to the stats report, once the base driver change has merged. I think that puts me in reasonable accord with your opinions? I think most admins won't bother setting this up, but might benefit from good defaults, but I think any admin who wants to customise it absolutely should be able to. In regards to a setting per volume type, that isn't really implemented in any easy-to-use way, and I think a clean implementation of that would be difficult to design and arguably not worth the effort - from the feedback on the operators list, it looks like most operators aren't using / don't understand the facilities we already have. If you really want to experiment with this sort of setup, you can achieve it with tertiary operators in the current code with a bit of though, e.g. type gold key=isgold, value=True type silver key=issilver value=True expression = (type.isgold? (<expression 1>):(type.issilver?(<expression 2>):(<default expression>))) It isn't neat and tidy, but it should work - the tool was designed with far more power and flexibility than most people need in part to allow weird experiments to be tried without having to change code. On 17 February 2015 at 08:00, Zhangli (ISSP) <zhangl...@huawei.com> wrote: > 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: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev