yahoo-eng-team team mailing list archive

["ChangBo Guo\(gcb\)" <glongwave@xxxxxxxxx>]

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