| 2015-07-08 17:14:11 |
Dina |
bug |
|
|
added bug |
| 2015-07-10 07:27:04 |
Markus Zoeller (markus_z) |
tags |
|
oslo |
|
| 2015-07-10 07:27:23 |
Markus Zoeller (markus_z) |
bug task added |
|
oslo.messaging |
|
| 2015-07-31 15:03:59 |
Liam Young |
oslo.messaging: status |
New |
Confirmed |
|
| 2015-07-31 15:07:39 |
Liam Young |
bug |
|
|
added subscriber Liam Young |
| 2015-07-31 15:16:13 |
Liam Young |
bug task added |
|
python-oslo.messaging (Ubuntu) |
|
| 2015-07-31 15:16:22 |
Liam Young |
oslo.messaging: status |
Confirmed |
Invalid |
|
| 2015-07-31 15:16:28 |
Liam Young |
nova: status |
New |
Invalid |
|
| 2015-07-31 15:16:35 |
Liam Young |
python-oslo.messaging (Ubuntu): status |
New |
Confirmed |
|
| 2015-08-04 18:00:56 |
Edward Hope-Morley |
tags |
oslo |
oslo sts |
|
| 2015-08-05 16:36:49 |
Edward Hope-Morley |
python-oslo.messaging (Ubuntu): status |
Confirmed |
In Progress |
|
| 2015-08-05 16:36:51 |
Edward Hope-Morley |
python-oslo.messaging (Ubuntu): assignee |
|
Edward Hope-Morley (hopem) |
|
| 2015-08-05 16:36:56 |
Edward Hope-Morley |
python-oslo.messaging (Ubuntu): importance |
Undecided |
High |
|
| 2015-08-06 10:44:28 |
Edward Hope-Morley |
affects |
python-oslo.messaging (Ubuntu) |
python-amqp (Ubuntu) |
|
| 2015-08-06 11:10:52 |
Edward Hope-Morley |
description |
On the latest update of the Ubuntu OpenStack packages, it was discovered that the nova-compute/nova-conductor (1:2014.1.4-0ubuntu2.1) packages encountered a bug with using SSL to connect to rabbitmq.
When this problem occurs, the compute node cannot connect to the controller, and this message is constantly displayed:
WARNING nova.conductor.api [req-4022395c-9501-47cf-bf8e-476e1cc58772 None None] Timed out waiting for nova-conductor. Is it running? Or did this service start before nova-conductor?
Investigation revealed that having rabbitmq configured with SSL was the root cause of this problem. This seems to have been introduced with the current version of the nova packages. Rabbitmq was not updated as part of this distribution update, but the messaging library (python-oslo.messaging 1.3.0-0ubuntu1.1) was updated. So the problem could exist in any of these components.
Versions installed:
Openstack version: Icehouse
Ubuntu 14.04.2 LTS
nova-conductor 1:2014.1.4-0ubuntu2.1
nova-compute 1:2014.1.4-0ubuntu2.1
rabbitmq-server 3.2.4-1
openssl:amd64/trusty-security 1.0.1f-1ubuntu2.15 |
[Impact]
Current oslo.messaging and python-amqp results in repeated connection timeouts in the amqp transport layer (SSLError) and thus excessive reconnect attempts. This is a known issues that was fixed in python-amqp 1.4.4.
[Test Case]
Deploy openstack using current Trusty versions + this version of python-amqp. Once up and running, check the following:
- number of rabbitmq connections - with single nova-compute, conductor etc I see approx 20 connections whereas previously i saw well over 100 and rising.
sudo rabbitmqctl list_connections
- check that messages are being consumed from openstack queues
sudo rabbitmqctl list_queues -p openstack consumers messages name
- also check e.g. nova-compute and nova-conductor logs and verify that the erros menioned below no longer appear
[Regression Potential]
None.
[Other Info]
None.
---- ---- ----- ----
On the latest update of the Ubuntu OpenStack packages, it was discovered that the nova-compute/nova-conductor (1:2014.1.4-0ubuntu2.1) packages encountered a bug with using SSL to connect to rabbitmq.
When this problem occurs, the compute node cannot connect to the controller, and this message is constantly displayed:
WARNING nova.conductor.api [req-4022395c-9501-47cf-bf8e-476e1cc58772 None None] Timed out waiting for nova-conductor. Is it running? Or did this service start before nova-conductor?
Investigation revealed that having rabbitmq configured with SSL was the root cause of this problem. This seems to have been introduced with the current version of the nova packages. Rabbitmq was not updated as part of this distribution update, but the messaging library (python-oslo.messaging 1.3.0-0ubuntu1.1) was updated. So the problem could exist in any of these components.
Versions installed:
Openstack version: Icehouse
Ubuntu 14.04.2 LTS
nova-conductor 1:2014.1.4-0ubuntu2.1
nova-compute 1:2014.1.4-0ubuntu2.1
rabbitmq-server 3.2.4-1
openssl:amd64/trusty-security 1.0.1f-1ubuntu2.15 |
|
| 2015-08-06 11:11:08 |
Edward Hope-Morley |
summary |
Using SSL with rabbitmq prevents communication between nova-compute and conductor after latest nova updates |
[SRU] Using SSL with rabbitmq prevents communication between nova-compute and conductor after latest nova updates |
|
| 2015-08-06 14:09:26 |
James Page |
nominated for series |
|
Ubuntu Trusty |
|
| 2015-08-06 14:09:26 |
James Page |
bug task added |
|
python-amqp (Ubuntu Trusty) |
|
| 2015-08-06 14:18:19 |
Edward Hope-Morley |
python-amqp (Ubuntu Trusty): status |
New |
In Progress |
|
| 2015-08-06 14:18:22 |
Edward Hope-Morley |
python-amqp (Ubuntu Trusty): importance |
Undecided |
High |
|
| 2015-08-06 14:18:25 |
Edward Hope-Morley |
python-amqp (Ubuntu Trusty): assignee |
|
Edward Hope-Morley (hopem) |
|
| 2015-08-06 14:56:19 |
Edward Hope-Morley |
branch linked |
|
lp:~hopem/ubuntu/trusty/python-amqp/lp1472712 |
|
| 2015-08-06 15:15:34 |
Edward Hope-Morley |
description |
[Impact]
Current oslo.messaging and python-amqp results in repeated connection timeouts in the amqp transport layer (SSLError) and thus excessive reconnect attempts. This is a known issues that was fixed in python-amqp 1.4.4.
[Test Case]
Deploy openstack using current Trusty versions + this version of python-amqp. Once up and running, check the following:
- number of rabbitmq connections - with single nova-compute, conductor etc I see approx 20 connections whereas previously i saw well over 100 and rising.
sudo rabbitmqctl list_connections
- check that messages are being consumed from openstack queues
sudo rabbitmqctl list_queues -p openstack consumers messages name
- also check e.g. nova-compute and nova-conductor logs and verify that the erros menioned below no longer appear
[Regression Potential]
None.
[Other Info]
None.
---- ---- ----- ----
On the latest update of the Ubuntu OpenStack packages, it was discovered that the nova-compute/nova-conductor (1:2014.1.4-0ubuntu2.1) packages encountered a bug with using SSL to connect to rabbitmq.
When this problem occurs, the compute node cannot connect to the controller, and this message is constantly displayed:
WARNING nova.conductor.api [req-4022395c-9501-47cf-bf8e-476e1cc58772 None None] Timed out waiting for nova-conductor. Is it running? Or did this service start before nova-conductor?
Investigation revealed that having rabbitmq configured with SSL was the root cause of this problem. This seems to have been introduced with the current version of the nova packages. Rabbitmq was not updated as part of this distribution update, but the messaging library (python-oslo.messaging 1.3.0-0ubuntu1.1) was updated. So the problem could exist in any of these components.
Versions installed:
Openstack version: Icehouse
Ubuntu 14.04.2 LTS
nova-conductor 1:2014.1.4-0ubuntu2.1
nova-compute 1:2014.1.4-0ubuntu2.1
rabbitmq-server 3.2.4-1
openssl:amd64/trusty-security 1.0.1f-1ubuntu2.15 |
[Impact]
Current oslo.messaging and python-amqp results in repeated connection timeouts in the amqp transport layer (SSLError) and thus excessive reconnect attempts. This is a known issues that was fixed in python-amqp 1.4.4.
[Test Case]
Deploy openstack using current Trusty versions + this version of python-amqp + rabbitmq configured to allow ssl connections only. Once up and running, check the following:
- number of rabbitmq connections - with single nova-compute, conductor etc I see approx 20 connections whereas previously i saw well over 100 and rising.
sudo rabbitmqctl list_connections
- check that messages are being consumed from openstack queues
sudo rabbitmqctl list_queues -p openstack consumers messages name
- also check e.g. nova-compute and nova-conductor logs and verify that the erros menioned below no longer appear
[Regression Potential]
None.
[Other Info]
None.
---- ---- ----- ----
On the latest update of the Ubuntu OpenStack packages, it was discovered that the nova-compute/nova-conductor (1:2014.1.4-0ubuntu2.1) packages encountered a bug with using SSL to connect to rabbitmq.
When this problem occurs, the compute node cannot connect to the controller, and this message is constantly displayed:
WARNING nova.conductor.api [req-4022395c-9501-47cf-bf8e-476e1cc58772 None None] Timed out waiting for nova-conductor. Is it running? Or did this service start before nova-conductor?
Investigation revealed that having rabbitmq configured with SSL was the root cause of this problem. This seems to have been introduced with the current version of the nova packages. Rabbitmq was not updated as part of this distribution update, but the messaging library (python-oslo.messaging 1.3.0-0ubuntu1.1) was updated. So the problem could exist in any of these components.
Versions installed:
Openstack version: Icehouse
Ubuntu 14.04.2 LTS
nova-conductor 1:2014.1.4-0ubuntu2.1
nova-compute 1:2014.1.4-0ubuntu2.1
rabbitmq-server 3.2.4-1
openssl:amd64/trusty-security 1.0.1f-1ubuntu2.15 |
|
| 2015-08-06 23:24:50 |
Nobuto Murata |
bug |
|
|
added subscriber Nobuto Murata |
| 2015-08-10 14:48:52 |
James Page |
python-amqp (Ubuntu): status |
In Progress |
Fix Released |
|
| 2015-08-10 14:58:27 |
James Page |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2015-08-12 15:47:00 |
Chris J Arges |
python-amqp (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2015-08-12 15:47:04 |
Chris J Arges |
bug |
|
|
added subscriber SRU Verification |
| 2015-08-12 15:47:13 |
Chris J Arges |
tags |
oslo sts |
oslo sts verification-needed |
|
| 2015-08-12 15:57:22 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/trusty-proposed/python-amqp |
|
| 2015-08-12 20:35:09 |
Dina |
tags |
oslo sts verification-needed |
oslo sts verification-done |
|
| 2015-08-20 19:41:57 |
Launchpad Janitor |
python-amqp (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2015-08-20 19:42:03 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
