| 2014-10-22 13:09:46 |
Doug Fish |
bug |
|
|
added bug |
| 2014-10-22 13:10:07 |
Doug Fish |
horizon: assignee |
|
Doug Fish (drfish) |
|
| 2014-10-22 13:10:50 |
Doug Fish |
summary |
Adjust metering units to sometime use a smaller unit |
Adjust metering time units to sometime use a smaller unit |
|
| 2014-10-22 13:11:11 |
Doug Fish |
description |
While reviewing https://review.openstack.org/#/c/96800 it seemed to me the code would sometimes select a larger unit that people would normally use to describe the data.
Consider these 2 representations of 2 data sets
Data set 1a: 15 sec 30 sec 45 sec 30 sec 75 sec
Data set 1b: .2 min .5 min .7 min 1.2 min
Data set 2a : 1 day 2 days 3 days 10 days 18 days
Data set 2b: .1 weeks .3 weeks .4 weeks 1.4 weeks 2.6 weeks
IMO the "a" version is how people normally think about the data, yet the metering unit code will select "b".
Specifically I think the metering unit selection code should not move to the next higher unit at 1 unit, but instead should convert at 2 or 3 units. |
While reviewing https://review.openstack.org/#/c/96800 it seemed to me the code would sometimes select a larger time unit that people would normally use to describe the data.
Consider these 2 representations of 2 data sets
Data set 1a: 15 sec 30 sec 45 sec 30 sec 75 sec
Data set 1b: .2 min .5 min .7 min 1.2 min
Data set 2a : 1 day 2 days 3 days 10 days 18 days
Data set 2b: .1 weeks .3 weeks .4 weeks 1.4 weeks 2.6 weeks
IMO the "a" version is how people normally think about the data, yet the metering unit code will select "b".
Specifically I think the metering time unit selection code should not move to the next higher unit at 1 unit, but instead should convert at 2 or 3 units. |
|
| 2014-10-22 19:24:21 |
Doug Fish |
description |
While reviewing https://review.openstack.org/#/c/96800 it seemed to me the code would sometimes select a larger time unit that people would normally use to describe the data.
Consider these 2 representations of 2 data sets
Data set 1a: 15 sec 30 sec 45 sec 30 sec 75 sec
Data set 1b: .2 min .5 min .7 min 1.2 min
Data set 2a : 1 day 2 days 3 days 10 days 18 days
Data set 2b: .1 weeks .3 weeks .4 weeks 1.4 weeks 2.6 weeks
IMO the "a" version is how people normally think about the data, yet the metering unit code will select "b".
Specifically I think the metering time unit selection code should not move to the next higher unit at 1 unit, but instead should convert at 2 or 3 units. |
While reviewing https://review.openstack.org/#/c/96800 it seemed to me the code would sometimes select a larger time unit that people would normally use to describe the data.
Consider these 2 representations of 2 data sets
Data set 1a: 15 sec 30 sec 45 sec 30 sec 75 sec
Data set 1b: .2 min .5 min .7 min 1.2 min
Data set 2a : 1 day 2 days 3 days 10 days 13 days
Data set 2b: .1 weeks .3 weeks .4 weeks 1.4 weeks 1.9 weeks
IMO the "a" version is how people normally think about the data, yet the metering unit code will select "b".
Specifically I think the metering time unit selection code should not move to the next higher unit at 1 unit, but instead should convert at 2 or 3 units. |
|
| 2014-10-22 19:30:40 |
OpenStack Infra |
horizon: status |
New |
In Progress |
|
| 2014-12-04 22:42:37 |
David Lyle |
horizon: importance |
Undecided |
Wishlist |
|
| 2014-12-05 00:11:34 |
OpenStack Infra |
horizon: status |
In Progress |
Fix Committed |
|
| 2014-12-05 04:08:15 |
Akihiro Motoki |
horizon: milestone |
|
kilo-1 |
|
| 2014-12-18 16:25:23 |
Thierry Carrez |
horizon: status |
Fix Committed |
Fix Released |
|
| 2015-04-30 08:24:21 |
Thierry Carrez |
horizon: milestone |
kilo-1 |
2015.1.0 |
|
