The interesting thing - we reproduced this issue against MOS 5.1 with Oslo messaging 1.4.1 - python-oslo-messaging-1.4.1-fuel6.0.mira18.noarch.rpm, while we updated only this packages and direct requirements,
without updating/installing only the followingthe following components:
python-oslo-config-1.4.0-fuel6.0.mira22.noarch.rpm
python-oslo-db-1.0.1-fuel6.0.mira21.noarch.rpm
python-oslo-vmware-0.6.0-fuel6.0.mira19.noarch.rpm
This updated python-oslo-messaging-1.4.1-fuel6.0.mira18 already includes latest fix to drivers/impl_rabbit.py, so it at least re-uses existing RabbitMQ queues.
MOS Oslo team suggests the issue may be somewhere in Ceilometer.
Please check same upstream bug: /bugs.launchpad .net/ceilometer /+bug/1337715
https:/
The interesting thing - we reproduced this issue against MOS 5.1 with Oslo messaging 1.4.1 - python- oslo-messaging- 1.4.1-fuel6. 0.mira18. noarch. rpm, while we updated only this packages and direct requirements, oslo-config- 1.4.0-fuel6. 0.mira22. noarch. rpm oslo-db- 1.0.1-fuel6. 0.mira21. noarch. rpm oslo-vmware- 0.6.0-fuel6. 0.mira19. noarch. rpm
without updating/installing only the followingthe following components:
python-
python-
python-
This updated python- oslo-messaging- 1.4.1-fuel6. 0.mira18 already includes latest fix to drivers/ impl_rabbit. py, so it at least re-uses existing RabbitMQ queues.
MOS Oslo team suggests the issue may be somewhere in Ceilometer.
MOS Oslo team, could you please confirm?