Bug 977903 - nova [logger]: it would be very helpful for debugging if we can print the command and its params to the logs
nova [logger]: it would be very helpful for debugging if we can print the com...
Status: CLOSED WONTFIX
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova (Show other bugs)
unspecified
x86_64 Linux
low Severity low
: ---
: 5.0 (RHEL 7)
Assigned To: Solly Ross
Ami Jeain
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-25 10:48 EDT by Dafna Ron
Modified: 2014-09-08 01:39 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-08 16:53:39 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 (79.21 KB, application/x-gzip)
2013-06-25 10:48 EDT, Dafna Ron
no flags Details

  None (edit)
Description Dafna Ron 2013-06-25 10:48:16 EDT
Created attachment 765119 [details]
logs

Description of problem:

It would be very helpful for debugging if we print the commands run + their params to the logs in status INFO. 

for example, if I have an instance that failed to run and was moved to error status it will be easier for me to locate the correlation id if I can find the command in the logs. 

Version-Release number of selected component (if applicable):
[root@opens-vdsb tmp(keystone_admin)]# rpm -qa |grep nova
python-novaclient-2.13.0-1.el6ost.noarch
openstack-nova-scheduler-2013.1.2-2.el6ost.noarch
openstack-nova-compute-2013.1.2-2.el6ost.noarch
python-nova-2013.1.2-2.el6ost.noarch
openstack-nova-api-2013.1.2-2.el6ost.noarch
openstack-nova-console-2013.1.2-2.el6ost.noarch
openstack-nova-conductor-2013.1.2-2.el6ost.noarch
openstack-nova-novncproxy-0.4-6.el6ost.noarch
openstack-nova-common-2013.1.2-2.el6ost.noarch
openstack-nova-cert-2013.1.2-2.el6ost.noarch
openstack-nova-network-2013.1.2-2.el6ost.noarch

How reproducible:

100%

Steps to Reproduce:
1. create an nfs server
2. create a volume
3. block connectivity to the nfs server from the compute using iptables iptables -A OUTPUT -d <nfs_server>  -j DROP
4. boot an instance using the volume: nova boot --flavor 2  --block_device_mapping=vda=<Vol_UUID>::: <name>
5. once the instance moves to error try to find it in the logs and the reason it was moved to error

Actual results:

I could not find my instance in the log using the UUID

Expected results:

if we print the commands with the params with correlation id it will be easy to find in the logs. 

Additional info: logs

root@opens-vdsb tmp(keystone_admin)]# nova list
+--------------------------------------+--------+--------+---------------------------+
| ID                                   | Name   | Status | Networks                  |
+--------------------------------------+--------+--------+---------------------------+
| 345a938d-a403-4e74-a017-4f4b119e4d33 | dafna5 | ERROR  |                           |
| 8f107ee9-809f-45c3-b062-520968e53bb5 | rhel   | ACTIVE | novanetwork=192.168.32.2  |
| 651650e2-5572-4b5a-9e4d-c9d49f041126 | rhel2  | ACTIVE | novanetwork=192.168.32.4  |
| 934afe50-4b37-4000-b2aa-7e471694aa15 | rhel3  | ACTIVE | novanetwork=192.168.32.5  |
| 4e365d61-ecd3-4721-a09b-32e96301999f | rhel4  | ACTIVE | novanetwork=192.168.32.6  |
| fdec3ef8-f72c-4b5f-8683-95be5b1de181 | rhel5  | ACTIVE | novanetwork=192.168.32.7  |
| 848b7a4e-c947-4fbc-a9a4-ede894742f29 | rhel6  | ACTIVE | novanetwork=192.168.32.8  |
| 1d7a4ec1-e29c-44c7-a241-b868e4b6b5ac | rhel7  | ACTIVE | novanetwork=192.168.32.9  |
| df68dd9d-c03a-4fbe-87f8-417d4a4e0329 | rhel8  | ACTIVE | novanetwork=192.168.32.10 |
| ada6ac8a-1ae2-4b0e-b551-67265adb61ec | rhel9  | ACTIVE | novanetwork=192.168.32.11 |
+--------------------------------------+--------+--------+---------------------------+
Comment 1 Solly Ross 2013-10-17 14:13:52 EDT
What is your logging configuration?  Have you enabled verbose or debug?
Comment 2 Dafna Ron 2013-10-18 04:59:10 EDT
I don't want to enable verbose or debug because I can't work with my logs in permanent debug because they would get too big too fast. 
Also, this bug is because I think that print of command should be in INFO not debug
Comment 3 Russell Bryant 2013-10-18 09:55:12 EDT
I don't think "if we print the commands with the params with correlation id it will be easy to find in the logs." is the right solution here.  However, we can certainly look at this specific failure case and figure out where we're not logging an error and add one.
Comment 4 Solly Ross 2014-04-08 16:53:39 EDT
As Russell said, this isn't really feasible.

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