yahoo-eng-team team mailing list archive

[John Garbutt <john@xxxxxxxxxxxxxxx>]

Public bug reported:

On a fresh deployment, there are issues when starting up nova-compute,
before nova-conductor has started responding to RPC requests.

The first is a MessagingTimeout in the _determine_version_cap call, that
is triggered by creating the ComputeManager class.

This cases the process to exit, but it doesn't seem to quite fully exit
the process.

It seems like this happens only when CONF.upgrade_levels.compute =
"auto"

This was spotted in this OSA change:
https://review.openstack.org/#/c/367752

** Affects: nova
     Importance: Medium
     Assignee: John Garbutt (johngarbutt)
         Status: In Progress

** Changed in: nova
     Assignee: (unassigned) => John Garbutt (johngarbutt)

** Changed in: nova
   Importance: Undecided => Medium

** Changed in: nova
       Status: New => In Progress

** Description changed:

  On a fresh deployment, there are issues when starting up nova-compute,
  before nova-conductor has started responding to RPC requests.
  
  The first is a MessagingTimeout in the _determine_version_cap call, that
  is triggered by creating the ComputeManager class.
  
  This cases the process to exit, but it doesn't seem to quite fully exit
  the process.
+ 
+ It seems like this happens only when CONF.upgrade_levels.compute =
+ "auto"
+ 
+ This was spotted in this OSA change:
+ https://review.openstack.org/#/c/367752

-- 
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/1631918

Title:
  _determine_version_cap fails with MessagingTimeout when starting nova-
  compute

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  On a fresh deployment, there are issues when starting up nova-compute,
  before nova-conductor has started responding to RPC requests.

  The first is a MessagingTimeout in the _determine_version_cap call,
  that is triggered by creating the ComputeManager class.

  This cases the process to exit, but it doesn't seem to quite fully
  exit the process.

  It seems like this happens only when CONF.upgrade_levels.compute =
  "auto"

  This was spotted in this OSA change:
  https://review.openstack.org/#/c/367752

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1631918/+subscriptions