Open Stack

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) <zhangli09 at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150217/e4c60a7e/attachment.html>