** Also affects: ceilometer/havana
Importance: Undecided
Status: New
** Changed in: ceilometer/havana
Status: New => In Progress
** Changed in: ceilometer/havana
Importance: Undecided => High
** Changed in: cinder
Importance: Undecided => High
** Also affects: cinder/havana
Importance: Undecided
Status: New
** Changed in: cinder/havana
Importance: Undecided => High
** Changed in: cinder/havana
Status: New => In Progress
** Changed in: ceilometer/havana
Milestone: None => 2013.2.1
** Changed in: cinder/havana
Milestone: None => 2013.2.1
** Changed in: cinder/havana
Assignee: (unassigned) => Flavio Percoco (flaper87)
** Changed in: ceilometer/havana
Assignee: (unassigned) => Eoghan Glynn (eglynn)
** Also affects: nova/havana
Importance: Undecided
Status: New
** Changed in: nova/havana
Importance: Undecided => High
** Changed in: nova/havana
Status: New => In Progress
** Changed in: nova/havana
Assignee: (unassigned) => Flavio Percoco (flaper87)
** Changed in: nova/havana
Milestone: None => 2013.2.1
** Also affects: heat/havana
Importance: Undecided
Status: New
** Changed in: heat/havana
Importance: Undecided => High
** Changed in: heat/havana
Status: New => In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1251757
Title:
On restart of QPID broker, fanout no longer works
Status in OpenStack Telemetry (Ceilometer):
In Progress
Status in Ceilometer havana series:
In Progress
Status in Cinder:
In Progress
Status in Cinder havana series:
In Progress
Status in Orchestration API (Heat):
Fix Committed
Status in heat havana series:
In Progress
Status in OpenStack Neutron (virtual network service):
New
Status in neutron havana series:
New
Status in OpenStack Compute (Nova):
In Progress
Status in OpenStack Compute (nova) havana series:
In Progress
Status in Oslo - a Library of Common OpenStack Code:
Fix Released
Status in oslo havana series:
New
Status in Messaging API for OpenStack:
Fix Released
Bug description:
When the QPID broker is restarted, RPC servers attempt to re-connect.
This re-connection process is not done correctly for fanout
subscriptions - two subscriptions are established to the same fanout
address.
This problem is compounded by the fix to bug#1178375
https://bugs.launchpad.net/oslo/+bug/1178375
With this bug fix, when topology version 2 is used, the reconnect
attempt uses a malformed subscriber address.
For example, I have a simple RPC server script that attempts to
service "my-topic". When it initially connects to the broker using
topology-version 1, these are the subscriptions that are established:
(py27)[kgiusti@t530 work (master)]$ ./my-server.py --topology=1 --auto-delete
server-02
Running server, name=server-02 exchange=my-exchange topic=my-topic
namespace=my-namespace
Using QPID topology version 1
Enable auto-delete
Recevr openstack/my-topic ; {"node": {"x-declare": {"auto-delete": true,
"durable": true}, "type": "topic"}, "create": "always", "link": {"x-declare":
{"auto-delete": true, "exclusive": false, "durable": false}, "durable": true,
"name": "my-topic"}}
Recevr openstack/my-topic.server-02 ; {"node": {"x-declare": {"auto-delete":
true, "durable": true}, "type": "topic"}, "create": "always", "link":
{"x-declare": {"auto-delete": true, "exclusive": false, "durable": false},
"durable": true, "name": "my-topic.server-02"}}
Recevr my-topic_fanout ; {"node": {"x-declare": {"auto-delete": true,
"durable": false, "type": "fanout"}, "type": "topic"}, "create": "always",
"link": {"x-declare": {"auto-delete": true, "exclusive": true, "durable":
false}, "durable": true, "name":
"my-topic_fanout_489a3178fc704123b0e5e2fbee125247"}}
When I restart the qpid broker, the server reconnects using the
following subscriptions
Recevr my-topic_fanout ; {"node": {"x-declare": {"auto-delete": true,
"durable": false, "type": "fanout"}, "type": "topic"}, "create": "always",
"link": {"x-declare": {"auto-delete": true, "exclusive": true, "durable":
false}, "durable": true, "name":
"my-topic_fanout_b40001afd9d946a582ead3b7b858b588"}}
Recevr my-topic_fanout ; {"node": {"x-declare": {"auto-delete": true,
"durable": false, "type": "fanout"}, "type": "topic"}, "create": "always",
"link": {"x-declare": {"auto-delete": true, "exclusive": true, "durable":
false}, "durable": true, "name":
"my-topic_fanout_b40001afd9d946a582ead3b7b858b588"}}
^^^^--- Note: subscribing twice to the same exclusive address! (Bad!)
Recevr openstack/my-topic.server-02 ; {"node": {"x-declare": {"auto-delete":
true, "durable": true}, "type": "topic"}, "create": "always", "link":
{"x-declare": {"auto-delete": true, "exclusive": false, "durable": false},
"durable": true, "name": "my-topic.server-02"}}
Recevr openstack/my-topic ; {"node": {"x-declare": {"auto-delete": true,
"durable": true}, "type": "topic"}, "create": "always", "link": {"x-declare":
{"auto-delete": true, "exclusive": false, "durable": false}, "durable": true,
"name": "my-topic"}}
When using topology=2, the failure case is a bit different. On reconnect,
the fanout addresses are lacking proper topic names:
Recevr amq.topic/topic/openstack/my-topic ; {"link": {"x-declare":
{"auto-delete": true, "durable": false}}}
Recevr amq.topic/fanout/ ; {"link": {"x-declare": {"auto-delete": true,
"exclusive": true}}}
Recevr amq.topic/fanout/ ; {"link": {"x-declare": {"auto-delete": true,
"exclusive": true}}}
Recevr amq.topic/topic/openstack/my-topic.server-02 ; {"link": {"x-declare":
{"auto-delete": true, "durable": false}}}
Note again - two subscriptions to fanout, and 'my-topic' is missing
(it should be after that trailing /)
FYI - my test RPC server and client can be accessed here:
https://github.com/kgiusti/oslo-messaging-clients
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1251757/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
