Comment 3 for bug 1362604

Thanks for researching this problem Viktor! Sorry for late response, we've been busy as the Juno release is nearing.

The main point to keep in mind while we search for a solution is that existing configurations must remain working. I would vote for changing the scaling so that both strings and integers are considered a factor by which the volume is multiplied.

We would however need to transparently (and undocumented-ly) support the old behaviour, where the volume can be passed in as explicit. That would need to be detected and in that case, the scaling factor shouldn't be multiplied with volume.

In addition, the rate_of_change transformer should be modified to ensure that with either string or integer scale, it's the delta that's multiplied, not the volume.

The expr/formula approach and the Celsius-Fahrenheit example would be better suited for the new Arithmetic transformer (http://docs.openstack.org/developer/ceilometer/configuration.html#multi-meter-arithmetic-transformer).

Cheers,
Nejc