Back to bug 1034684
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Eoghan Glynn | 2013-11-26 10:53:38 UTC | Priority | unspecified | medium |
| Status | NEW | ASSIGNED | ||
| Target Release | --- | 4.0 | ||
| Assignee | rhos-maint | eglynn | ||
| Target Milestone | --- | rc | ||
| Eoghan Glynn | 2013-11-26 10:54:51 UTC | Link ID | OpenStack gerrit 58343 | |
| Ami Jeain | 2013-11-26 11:36:36 UTC | QA Contact | ajeain | kwhitney |
| Steven Dake | 2013-11-26 15:04:03 UTC | Keywords | OtherQA | |
| Eoghan Glynn | 2013-11-26 15:46:47 UTC | Link ID | OpenStack gerrit 58552 | |
| Eoghan Glynn | 2013-11-26 15:47:15 UTC | Status | ASSIGNED | POST |
| Steven Dake | 2013-11-27 14:58:04 UTC | Keywords | Triaged | |
| Eoghan Glynn | 2013-12-05 18:53:25 UTC | Status | POST | MODIFIED |
| Fixed In Version | openstack-heat-engine-2013.2-2.0.el6ost | |||
| errata-xmlrpc | 2013-12-05 19:03:10 UTC | Status | MODIFIED | ON_QA |
| Bruce Reeler | 2013-12-09 07:31:11 UTC | CC | breeler, eglynn | |
| Flags | needinfo?(eglynn) | |||
| Eoghan Glynn | 2013-12-09 16:55:42 UTC | Flags | needinfo?(eglynn) | |
| Bruce Reeler | 2013-12-11 05:48:40 UTC | Flags | needinfo?(eglynn) | |
| Eoghan Glynn | 2013-12-11 12:26:30 UTC | Doc Text | Cause: counter-intuitive truncation logic in the autoscaling calculation of server group growth/shrinkage. Consequence: depending the choice of initial size and adjustment, the autoscaling group scale-up and scale-down may not use all available headroom. Fix: intuitive truncation logic was implemented. Result: regardless of the choice of initial size and adjustment, the autoscaling group will always use all available headroom for scale-up and -down. | |
| Flags | needinfo?(eglynn) | |||
| Eoghan Glynn | 2013-12-11 16:59:23 UTC | Status | ON_QA | VERIFIED |
| Don Domingo | 2013-12-11 23:16:34 UTC | CC | ddomingo | |
| Doc Text | Cause: counter-intuitive truncation logic in the autoscaling calculation of server group growth/shrinkage. Consequence: depending the choice of initial size and adjustment, the autoscaling group scale-up and scale-down may not use all available headroom. Fix: intuitive truncation logic was implemented. Result: regardless of the choice of initial size and adjustment, the autoscaling group will always use all available headroom for scale-up and -down. | The heat engine used counterintuitive truncation logic when calculating the autoscaling of server group size changes. Specifically, autoscaling always only used the configured scaling increment, regardless of the configured maximum or minimum group size. This allowed certain scaling increment settings to prevent the autoscaling feature from actually hitting minimum or maximum group sizes. For example, with a scale-up setting of 2, the only possible autoscaling maximum would be 4 if the configured maximum group size if 5. With this release, the autoscaling feature now truncates scaling adjustments to upper/lower bounds in case of an overshoot. This allows the autoscaling feature to fully reach maximum and minimum group sizes, regardless of the configuring scaling increments. |
||
| Don Domingo | 2013-12-11 23:47:39 UTC | Doc Text | The heat engine used counterintuitive truncation logic when calculating the autoscaling of server group size changes. Specifically, autoscaling always only used the configured scaling increment, regardless of the configured maximum or minimum group size. This allowed certain scaling increment settings to prevent the autoscaling feature from actually hitting minimum or maximum group sizes. For example, with a scale-up setting of 2, the only possible autoscaling maximum would be 4 if the configured maximum group size if 5. With this release, the autoscaling feature now truncates scaling adjustments to upper/lower bounds in case of an overshoot. This allows the autoscaling feature to fully reach maximum and minimum group sizes, regardless of the configuring scaling increments. | The Orchestration engine used counterintuitive truncation logic when calculating the autoscaling of server group size changes. Specifically, autoscaling always only used the configured scaling increment, regardless of the configured maximum or minimum group size. This allowed certain scaling increment settings to prevent the autoscaling feature from actually hitting minimum or maximum group sizes. For example, with a scale-up setting of 2, the only possible autoscaling maximum would be 4 if the configured maximum group size if 5. With this release, the autoscaling feature now truncates scaling adjustments to upper/lower bounds in case of an overshoot. This allows the Orchestration engine to automatically scale to maximum and minimum group sizes, regardless of the configuring scaling increments. |
| errata-xmlrpc | 2013-12-19 17:42:07 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2013-12-20 00:39:08 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2013-12-19 19:39:08 UTC | |||
| John Skeoch | 2014-02-02 22:41:05 UTC | CC | srevivo |
Back to bug 1034684