Description of problem: The month part of the ansible log file name generated by cockpit is off by one, e.g. if I run it today (2019-12-26), I get: ovirt-hosted-engine-setup-ansible-bootstrap_local_vm-20191126145927-fyf60e.log that is, '11' instead of '12'. Other fields are not zero-padded, so might end up as a single digit, e.g.: ovirt-hosted-engine-setup-ansible-initial_clean-2019112614575-n6o7bu.log I looked at the code, and the reason seems to be that we use javascript's Date.getMonth as-is, which returns the month as an integer from 0 to 11, and also for the others, do not zero-pad. Version-Release number of selected component (if applicable): Current master. I think "forever" (since 4.2, bug 1555358). How reproducible: Always Steps to Reproduce: 1. Deploy hosted-engine from cockpit 2. Check generated log files' names 3. Actual results: The names have the month off by one, other fields are not zero-padded. Expected results: Same as other tools, e.g. 2019112614575 should have been 20191226145705. Additional info: I do not know javascript, and admit I was surprised to find out it has no date formatting in its standard library, similarly to e.g. python. See e.g.: https://stackoverflow.com/questions/23593052/format-javascript-date-as-yyyy-mm-dd
Test with ovirt-node-ng-installer-4.4.1-2020070507.el8.iso, the bug is fixed, move it to "VERIFIED" -rw-r--r--. 1 root root 100866 Jul 7 10:48 ovirt-hosted-engine-setup-ansible-bootstrap_local_vm-20200707104836-glkybn.log -rw-r--r--. 1 root root 130675 Jul 7 10:44 ovirt-hosted-engine-setup-ansible-get_network_interfaces-20200707104339-8vf13z.log -rw-r--r--. 1 root root 276983 Jul 7 10:48 ovirt-hosted-engine-setup-ansible-initial_clean-20200707104631-wv2mfi.log -rw-r--r--. 1 root root 132603 Jul 7 10:44 ovirt-hosted-engine-setup-ansible-validate_hostnames-20200707104339-ejuhyz.log -rw-r--r--. 1 root root 133581 Jul 7 10:45 ovirt-hosted-engine-setup-ansible-validate_hostnames-20200707104440-dhkms3.log
This bugzilla is included in oVirt 4.4.1 release, published on July 8th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.