Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 977903 - nova [logger]: it would be very helpful for debugging if we can print the command and its params to the logs
Summary: nova [logger]: it would be very helpful for debugging if we can print the com...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova
Version: unspecified
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
: 5.0 (RHEL 7)
Assignee: Solly Ross
QA Contact: Ami Jeain
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-25 14:48 UTC by Dafna Ron
Modified: 2019-09-09 15:13 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-08 20:53:39 UTC
Target Upstream Version:

Attachments (Terms of Use)
logs (79.21 KB, application/x-gzip)
2013-06-25 14:48 UTC, Dafna Ron 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

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.
Note You need to log in before you can comment on or make changes to this bug.