yahoo-eng-team team mailing list archive

[Matthew Gilliard <matthew.gilliard@xxxxxx>]

Public bug reported:

ComputeCapabilitiesFilter code is convoluted.  There are at least 3
different ways it can fail, and 2 of them don't provide any output at
all.  The one which does logs at debug (should be info), and does not
actually provide enough info to diagnose the problem.

The code around here
https://github.com/openstack/nova/blob/master/nova/scheduler/filters/compute_capabilities_filter.py#L33
and below could do with a nice bit of TLC.  For example:

- the for loop on line #49 can only ever be iterating on range(0,1) which is "once", ie no need for a loop.
- the redefinition of "cap" makes it difficult to reason about what data is being worked on.
- the above-mentioned lack of logging.

I recommend checking the strength of the unit tests also, to give
confidence that a refactoring doesn't introduce any regressions.

** Affects: nova
     Importance: Undecided
         Status: New

** Summary changed:

- ComputeCapabilitiesFilter doesn't provide enough debug output on failure
+ ComputeCapabilitiesFilter doesn't provide enough information on failure

** Description changed:

  ComputeCapabilitiesFilter code is convoluted.  There are at least 3
- different ways it can fail, and 2 of them don't provide any debug output
- at all.  The one which does logs at debug (should be info), and does not
+ different ways it can fail, and 2 of them don't provide any output at
+ all.  The one which does logs at debug (should be info), and does not
  actually provide enough info to diagnose the problem.
  https://github.com/openstack/nova/blob/master/nova/scheduler/filters/compute_capabilities_filter.py#L69
  Could do with a nice bit of TLC.

** Description changed:

  ComputeCapabilitiesFilter code is convoluted.  There are at least 3
  different ways it can fail, and 2 of them don't provide any output at
  all.  The one which does logs at debug (should be info), and does not
  actually provide enough info to diagnose the problem.
- https://github.com/openstack/nova/blob/master/nova/scheduler/filters/compute_capabilities_filter.py#L69
- Could do with a nice bit of TLC.
+ 
+ The code around here
+ https://github.com/openstack/nova/blob/master/nova/scheduler/filters/compute_capabilities_filter.py#L33
+ and below could do with a nice bit of TLC.  For example:
+ 
+ - the for loop on line #49 can only ever be iterating on range(0,1) which is "once", ie no need for a loop.
+ - the redefinition of "cap" makes it difficult to reason about what data is being worked on.
+ - the above-mentioned lack of logging.
+ 
+ Recommend checking the strength of the unit tests also, to give
+ confidence that a refactoring doesn't introduce any regressions.

** Description changed:

  ComputeCapabilitiesFilter code is convoluted.  There are at least 3
  different ways it can fail, and 2 of them don't provide any output at
  all.  The one which does logs at debug (should be info), and does not
  actually provide enough info to diagnose the problem.
  
  The code around here
  https://github.com/openstack/nova/blob/master/nova/scheduler/filters/compute_capabilities_filter.py#L33
  and below could do with a nice bit of TLC.  For example:
  
  - the for loop on line #49 can only ever be iterating on range(0,1) which is "once", ie no need for a loop.
  - the redefinition of "cap" makes it difficult to reason about what data is being worked on.
  - the above-mentioned lack of logging.
  
- Recommend checking the strength of the unit tests also, to give
+ I recommend checking the strength of the unit tests also, to give
  confidence that a refactoring doesn't introduce any regressions.

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

Title:
  ComputeCapabilitiesFilter doesn't provide enough information on
  failure

Status in OpenStack Compute (Nova):
  New

Bug description:
  ComputeCapabilitiesFilter code is convoluted.  There are at least 3
  different ways it can fail, and 2 of them don't provide any output at
  all.  The one which does logs at debug (should be info), and does not
  actually provide enough info to diagnose the problem.

  The code around here
  https://github.com/openstack/nova/blob/master/nova/scheduler/filters/compute_capabilities_filter.py#L33
  and below could do with a nice bit of TLC.  For example:

  - the for loop on line #49 can only ever be iterating on range(0,1) which is "once", ie no need for a loop.
  - the redefinition of "cap" makes it difficult to reason about what data is being worked on.
  - the above-mentioned lack of logging.

  I recommend checking the strength of the unit tests also, to give
  confidence that a refactoring doesn't introduce any regressions.

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