yahoo-eng-team team mailing list archive

[Sam Yaple <sam@xxxxxxxxx>]

Public bug reported:

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

** Affects: nova
     Importance: Undecided
         Status: New

-- 
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):
  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