Hide Forgot
Description of problem: When switching a host to maintenanace, event msg has strange text for 'reason' part, see below: 2016-01-22 12:29:29,733 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-7-thread-37) [6b4d26fe] Correlation ID: 6b4d26fe, Job ID: aec84f47-c5dc-421d-974a-11d6af19f518, Call Stack: null, Custom Event ID: -1, Message: Host 10.34.62.204 was switched to Maintenance mode by admin@internal (Reason: No reason was returned for this operation failure. See logs for further details.). The switch to maintenance finished ok, so why ...failure... ? Version-Release number of selected component (if applicable): rhevm-backend-3.6.2.6-0.1.el6.noarch How reproducible: 100% Steps to Reproduce: 1. switch a host to maintenance 2. observe related events msgs for their content 3. Actual results: strange text for reason part Expected results: reason text part should make sense, no "failure" if everything finished OK Additional info:
We can solve this is a couple of ways. Please note that on the cluster level there is an option: "Enable to set Host maintenance reason" When a reason is provided by the host admin there is no problem. When the reason is not provided we could: Option 1: always write: -- Host bodh1 was switched to Maintenance mode by admin@internal-authz (Reason: No reason was given). Option 2: If the option on the cluster level is turned OFF (admin can't provide reason) write: -- Host bodh1 was switched to Maintenance mode by admin@internal-authz If its ON (admin can provide reason) write: -- Host bodh1 was switched to Maintenance mode by admin@internal-authz (Reason: No reason was given). Option 3: -- Disregarding the cluster option, if there is no reason given always write Host bodh1 was switched to Maintenance mode by admin@internal-authz I would go with option three because we do not loose any useful information in the logs and at the same time we do not create additional coupling in the code with the cluster object. I implemented that option, but it took only a few minutes so I am not attached to it if one of the other options is better.
ok, 4.0.0-19 # grep 'was switched to Maintenance' /var/log/ovirt-engine/engine.log 2016-07-01 17:19:45,869 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-11) [751ed17d] Correlation ID: 751ed17d, Job ID: a864835f-22bc-4533-8089-7cbd47655ff1, Call Stack: null, Custom Event ID: -1, Message: Host dell-r210ii-04 was switched to Maintenance mode by admin@internal-authz. 2016-07-01 17:21:38,049 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-16) [80f69d4] Correlation ID: 80f69d4, Job ID: e4161d60-f00f-475f-b337-a3bba2ce739a, Call Stack: null, Custom Event ID: -1, Message: Host dell-r210ii-04 was switched to Maintenance mode by admin@internal-authz. 2016-07-01 17:24:05,282 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-21) [406e95f0] Correlation ID: 406e95f0, Job ID: 9a788af3-cb8c-42e1-ae6c-a4773c8c52d7, Call Stack: null, Custom Event ID: -1, Message: Host dell-r210ii-04 was switched to Maintenance mode by admin@internal-authz (Reason: protoze proto).
oVirt 4.0.0 has been released, closing current release.