yahoo-eng-team team mailing list archive

[melanie witt <1595965@xxxxxxxxxxxxxxxxxx>]

It appears this has been fixed in oslo.messaging and was not related to
nova. Please re-open this bug if that's not the case.

** Changed in: nova
       Status: Incomplete => Invalid

-- 
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):
  Invalid
Status in oslo.messaging:
  Fix Released

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