Description of problem: This is similar to bz 1624732, but on ovirt-hosted-engine-ha. Due to a change in the output of 'openssl x509 -subject', it fails to get the hostname from the subject, and logs something like this: MainThread::INFO::2021-07-21 07:22:31,462::hosted_engine::242::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_get_hostname) Certificate common name not found, using hostname to identify host In principle this is harmless, in most cases. The only risk in not fixing it is if two HA hosts in the same cluster have the same hostname but different names in their certs - in practice, we never received such a report. There is a small risk in fixing this bug for existing setups - if the hostname is different than the name in the cert, it might affect other things, including reporting, output of 'hosted-engine --vm-status', etc. Version-Release number of selected component (if applicable): Since openssl changed its -subject format output. According to bz 1624732, that was around the release of Fedora 28. How reproducible: Always Steps to Reproduce: 1. Deploy hosted-engine 2. grep 'Certificate common name not found' /var/log/ovirt-hosted-engine-ha/agent.log 3. Actual results: As above Expected results: Empty output Additional info: As explained, it might be best to not fix. If we decide to fix, I see two options: 1. Do some thorough testing on upgrade flows with a fixed version, before deciding if we want it. 2. Make the fix not apply on upgrade flows. How to decide if that's an upgrade? Probably based on whether the host already has an entry in the shared storage - if it does, perhaps take the hostname from there, or at least log if they are different.
This was reported at: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/DTEY6OTBIWNX2DKGA7M7ZGUZZNQJYZXW/
Given the possibility that same hostname in the same cluster is remote and this is harmless otherwise, closing wontfix.