Bug 1984262

Summary: The agent fails to parse its certificate's subject
Product: [oVirt] ovirt-hosted-engine-ha Reporter: Yedidyah Bar David <didi>
Component: AgentAssignee: Asaf Rachmani <arachman>
Status: CLOSED WONTFIX QA Contact: meital avital <mavital>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: ---CC: bugs
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-07-29 07:16:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Integration RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Yedidyah Bar David 2021-07-21 05:42:07 UTC
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.

Comment 2 Sandro Bonazzola 2021-07-29 07:16:12 UTC
Given the possibility that same hostname in the same cluster is remote and this is harmless otherwise, closing wontfix.