Bug 977903

Summary: nova [logger]: it would be very helpful for debugging if we can print the command and its params to the logs
Product: Red Hat OpenStack Reporter: Dafna Ron <dron>
Component: openstack-novaAssignee: Solly Ross <sross>
Status: CLOSED WONTFIX QA Contact: Ami Jeain <ajeain>
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: dallan, dron, jkt, ndipanov, sgordon, sross, yeylon
Target Milestone: ---Keywords: Triaged
Target Release: 5.0 (RHEL 7)   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-08 20:53:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
logs none

Description Dafna Ron 2013-06-25 14:48:16 UTC
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 18:13:52 UTC
What is your logging configuration?  Have you enabled verbose or debug?

Comment 2 Dafna Ron 2013-10-18 08:59:10 UTC
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 13:55:12 UTC
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 20:53:39 UTC
As Russell said, this isn't really feasible.