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 | +--------------------------------------+--------+--------+---------------------------+
What is your logging configuration? Have you enabled verbose or debug?
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
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.
As Russell said, this isn't really feasible.