this feels like it may very well be an issue in oslo.service itself,
adding that
** Also affects: oslo.service
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Incomplete
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1595965
Title:
transport_url is being parsed different when forking with oslo.service
Status in OpenStack Compute (nova):
Incomplete
Status in oslo.service:
New
Bug description:
This is a strange one. I had setup my transport_url incorrectly which
made me discover this. I am filing this bug because I believe there is
one.
When using a correctly formatted transport_url that was missing data
_and_ multiple workers for conductor it would incorrectly parse the
transport_url.
Here is the incorrect transport_url:
rabbit://<user>:<pass>@server01,server02/openstack
The correct transport_url should be:
rabbit://<user>:<pass>@server01,<user>:<pass>@server02/openstack
According to the docs [1], when the username and password is not
specified, the server should be omitted from the list of servers. So
for the incorrect transport_url only server01 would be setup. Here is
a list of scenarios and what the behavior I see is.
* with the incorrect transport_url and a single thread all services contact
only server01
* with the incorrect transport_url and multiple threads all services contact
only server01 _except_ conductor which will attempt to contact server02 with
the default username and password
* with the correct transport_url all services contact server01 and server02
properly
To reproduce this, get two rabbitmq hosts and set the incorrect
transport_url and at least 2 conductor workers. Look at the rabbitmq
logs on server02 and youll see it is trying to login via the guest
user. Set the number of workers to 1 and notice there is no bad logins
in rabbitmq logs. Fix the transport_url and it will use all servers
appropriately no matter the number of workers.
The following is a gut feeling. I believe the issue is around the
point it gets forked with oslo.service. It may not properly be
reparsing the transport_url. I couldn't prove that though.
Nova versions tested: 13.0.0 and 13.1.0
all libraries were within the upper-constraints for mitaka
[1] http://docs.openstack.org/developer/oslo.messaging/transport.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1595965/+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
