Bug 976381 - nova: inconsistency between print of nova-manage flavor list and nova flavor-list
nova: inconsistency between print of nova-manage flavor list and nova flavor-...
Status: CLOSED NOTABUG
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova (Show other bugs)
unspecified
x86_64 Linux
unspecified Severity low
: ---
: 4.0
Assigned To: Vladan Popovic
Ami Jeain
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-20 09:15 EDT by Dafna Ron
Modified: 2016-04-26 17:21 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-03 05:49:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
logs (773.20 KB, application/x-gzip)
2013-06-20 09:15 EDT, Dafna Ron
no flags Details

  None (edit)
Description Dafna Ron 2013-06-20 09:15:13 EDT
Created attachment 763466 [details]
logs

Description of problem:

nova-manage flavor list will print: 

2013-06-20 16:07:48.991 DEBUG nova.openstack.common.lockutils [req-a16c234d-1d7e-48ea-af4e-d92d8caf414f None None] Got semaphore "dbapi_backend" for method "__get_backend"... inner /usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py:186
m1.medium: Memory: 4096MB, VCPUS: 2, Root: 40GB, Ephemeral: 0Gb, FlavorID: 3, Swap: 0MB, RXTX Factor: 1.0, public, ExtraSpecs {}
m1.large: Memory: 8192MB, VCPUS: 4, Root: 80GB, Ephemeral: 0Gb, FlavorID: 4, Swap: 0MB, RXTX Factor: 1.0, public, ExtraSpecs {}
m1.tiny: Memory: 512MB, VCPUS: 1, Root: 0GB, Ephemeral: 0Gb, FlavorID: 1, Swap: 0MB, RXTX Factor: 1.0, public, ExtraSpecs {}
m1.xlarge: Memory: 16384MB, VCPUS: 8, Root: 160GB, Ephemeral: 0Gb, FlavorID: 5, Swap: 0MB, RXTX Factor: 1.0, public, ExtraSpecs {}
m1.small: Memory: 2048MB, VCPUS: 1, Root: 20GB, Ephemeral: 0Gb, FlavorID: 2, Swap: 0MB, RXTX Factor: 1.0, public, ExtraSpecs {}

nova flavor-list will print: 

root@opens-vdsb log(keystone_admin)]# nova flavor-list 
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| ID | Name      | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | extra_specs |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| 1  | m1.tiny   | 512       | 0    | 0         |      | 1     | 1.0         | True      | {}          |
| 2  | m1.small  | 2048      | 20   | 0         |      | 1     | 1.0         | True      | {}          |
| 3  | m1.medium | 4096      | 40   | 0         |      | 2     | 1.0         | True      | {}          |
| 4  | m1.large  | 8192      | 80   | 0         |      | 4     | 1.0         | True      | {}          |
| 5  | m1.xlarge | 16384     | 160  | 0         |      | 8     | 1.0         | True      | {}          |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+

I think that since both are under the same component we should have consistency in how we print the output 

Version-Release number of selected component (if applicable):

openstack-nova-compute-2013.1.2-2.el6ost.noarch

How reproducible:

100%

Steps to Reproduce:
1. run 'nova flavor-list'
2. run 'nova-manage flavor list'
3.

Actual results:

the output is printed differently

Expected results:

we should have consistency 

Additional info: don't think its needed bit nova logs are attached any way.
Comment 1 Nikola Dipanov 2013-10-03 05:49:51 EDT
I am assuming that consistency in how the output is printed makes sense as a bug if we assume that the two tools are interchangeable and parsing their output by a program should be made as straightforward as possible.

This is however not the case! For more information about nova-manage and how it should be used and supported within our products see https://bugzilla.redhat.com/show_bug.cgi?id=910717. Based on that - we really should not be putting any effort in making nova-manage output accessible let alone follow what the CLI clients are doing.

I am closing this as invalid.

Note You need to log in before you can comment on or make changes to this bug.