| 2013-08-05 17:40:04 |
Thomas Maddox |
bug |
|
|
added bug |
| 2013-08-05 18:24:03 |
Thomas Maddox |
description |
I ran into this specifically when spinning up new instances, I found that as the instance was well into the active state from the horizon perspective, the resource-show on that instance was showing 'scheduling' as the state, which is incorrect. It even persisted that way after a delete on the same instance.
Potentially related bug: https://bugs.launchpad.net/ceilometer/+bug/1201701
Here's Ceilometer client output for an instance where this was happening
http://paste.openstack.org/show/42963/ |
I ran into this specifically when spinning up new instances, I found that as the instance was well into the active state from the horizon perspective, the resource-show on that instance was showing 'scheduling' as the state, which is incorrect. It even persisted that way after a delete on the same instance.
Potentially related bug: https://bugs.launchpad.net/ceilometer/+bug/1201701
Here's Ceilometer client output for an instance where this was happening
http://paste.openstack.org/show/42963/
The thinking is that we are having the metadata overwritten because we don't check the timestamp to prevent overwriting the current state with an old message's metadata. |
|
| 2013-08-05 18:25:37 |
Thomas Maddox |
description |
I ran into this specifically when spinning up new instances, I found that as the instance was well into the active state from the horizon perspective, the resource-show on that instance was showing 'scheduling' as the state, which is incorrect. It even persisted that way after a delete on the same instance.
Potentially related bug: https://bugs.launchpad.net/ceilometer/+bug/1201701
Here's Ceilometer client output for an instance where this was happening
http://paste.openstack.org/show/42963/
The thinking is that we are having the metadata overwritten because we don't check the timestamp to prevent overwriting the current state with an old message's metadata. |
I ran into this specifically when spinning up new instances, I found that as the instance was well into the active state from the horizon perspective, the resource-show on that instance was showing 'scheduling' as the state, which is incorrect. It even persisted that way after a delete on the same instance.
Potentially related bug: https://bugs.launchpad.net/ceilometer/+bug/1201701
Here's Ceilometer client output for an instance where this was happening
http://paste.openstack.org/show/42963/
The thinking is that we are having the metadata overwritten because we don't check the timestamp to prevent overwriting the current state with an old message's metadata.
If message 2 arrives at CM before message 1 because it ended up on a faster route and/or the message queue doesn't guarantee order, then message 1 will overwrite the metadata from message 2 and we record an incorrect state. |
|
| 2013-08-06 20:25:20 |
Thomas Maddox |
description |
I ran into this specifically when spinning up new instances, I found that as the instance was well into the active state from the horizon perspective, the resource-show on that instance was showing 'scheduling' as the state, which is incorrect. It even persisted that way after a delete on the same instance.
Potentially related bug: https://bugs.launchpad.net/ceilometer/+bug/1201701
Here's Ceilometer client output for an instance where this was happening
http://paste.openstack.org/show/42963/
The thinking is that we are having the metadata overwritten because we don't check the timestamp to prevent overwriting the current state with an old message's metadata.
If message 2 arrives at CM before message 1 because it ended up on a faster route and/or the message queue doesn't guarantee order, then message 1 will overwrite the metadata from message 2 and we record an incorrect state. |
I ran into this specifically when spinning up new instances, I found that as the instance was well into the active state from the horizon perspective, the resource-show on that instance was showing 'scheduling' as the state, which is incorrect. It even persisted that way after a delete on the same instance.
Potentially related bug: https://bugs.launchpad.net/ceilometer/+bug/1201701
Here's Ceilometer client output for an instance where this was happening
http://paste.openstack.org/show/42963/
The thinking is that we are having the metadata overwritten because we don't check the timestamp to prevent overwriting the current state with an old message's metadata.
If message 2 arrives at CM before message 1 because it ended up on a faster route and AMQP doesn't guarantee order, then message 1 will overwrite the metadata from message 2 and we record an incorrect state. |
|
| 2013-08-07 13:22:58 |
Thomas Maddox |
ceilometer: assignee |
|
Thomas Maddox (thomas-maddox) |
|
| 2013-08-23 11:45:43 |
Julien Danjou |
ceilometer: status |
New |
Triaged |
|
| 2013-08-23 11:45:45 |
Julien Danjou |
ceilometer: importance |
Undecided |
Medium |
|
| 2013-08-23 11:45:54 |
Julien Danjou |
ceilometer: milestone |
|
havana-3 |
|
| 2013-08-23 12:55:44 |
Thomas Maddox |
ceilometer: status |
Triaged |
In Progress |
|
| 2013-08-23 12:57:06 |
Thomas Maddox |
tags |
|
grizzly-backport-potential |
|
| 2013-08-23 12:59:07 |
Thomas Maddox |
description |
I ran into this specifically when spinning up new instances, I found that as the instance was well into the active state from the horizon perspective, the resource-show on that instance was showing 'scheduling' as the state, which is incorrect. It even persisted that way after a delete on the same instance.
Potentially related bug: https://bugs.launchpad.net/ceilometer/+bug/1201701
Here's Ceilometer client output for an instance where this was happening
http://paste.openstack.org/show/42963/
The thinking is that we are having the metadata overwritten because we don't check the timestamp to prevent overwriting the current state with an old message's metadata.
If message 2 arrives at CM before message 1 because it ended up on a faster route and AMQP doesn't guarantee order, then message 1 will overwrite the metadata from message 2 and we record an incorrect state. |
I ran into this specifically when spinning up new instances, I found that as the instance was well into the active state from the horizon perspective, the resource-show on that instance was showing 'scheduling' as the state, which is incorrect. It even persisted that way after a delete on the same instance.
Related bugs:
1. Glance metadata mismatch: https://bugs.launchpad.net/ceilometer/+bug/1201701
2. Too low precision on timestamps: https://bugs.launchpad.net/ceilometer/+bug/1215676
Here's Ceilometer client output for an instance where this was happening
http://paste.openstack.org/show/42963/
The thinking is that we are having the metadata overwritten because we don't check the timestamp to prevent overwriting the current state with an old message's metadata.
If message 2 arrives at CM before message 1 because it ended up on a faster route and AMQP doesn't guarantee order, then message 1 will overwrite the metadata from message 2 and we record an incorrect state. |
|
| 2013-09-04 05:42:56 |
OpenStack Infra |
ceilometer: assignee |
Thomas Maddox (thomas-maddox) |
Tong Li (litong01) |
|
| 2013-09-04 13:04:11 |
OpenStack Infra |
ceilometer: assignee |
Tong Li (litong01) |
Thomas Maddox (thomas-maddox) |
|
| 2013-09-05 09:37:46 |
Thierry Carrez |
ceilometer: milestone |
havana-3 |
havana-rc1 |
|
| 2013-09-10 10:38:03 |
OpenStack Infra |
ceilometer: status |
In Progress |
Fix Committed |
|
| 2013-10-02 19:07:20 |
Thierry Carrez |
ceilometer: status |
Fix Committed |
Fix Released |
|
| 2013-10-15 19:49:51 |
Alan Pevec |
tags |
grizzly-backport-potential |
|
|
| 2013-10-17 09:37:13 |
Thierry Carrez |
ceilometer: milestone |
havana-rc1 |
2013.2 |
|
