In http://docs.openstack.org/developer/oslo.messaging/transport.html
Username and password should be specified for each host, in case of lack of specification they will be omitted: user:pass@host1:port1,host2:port2 [ {"username": "user", "password": "pass", "host": "host1:port1"}, {"host": "host2:port2"} ] I doesn't mean the server is ommited , but username/password are ommited. so It works as design. We can make it more clear about this, maybe a warning is logged in this case. ** No longer affects: oslo.service ** Also affects: oslo.messaging Importance: Undecided Status: New ** Changed in: oslo.messaging Assignee: (unassigned) => ChangBo Guo(gcb) (glongwave) -- 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.messaging: In Progress 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