Bug 1984262 - The agent fails to parse its certificate's subject
Summary: The agent fails to parse its certificate's subject
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-hosted-engine-ha
Classification: oVirt
Component: Agent
Version: ---
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Asaf Rachmani
QA Contact: meital avital
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-07-21 05:42 UTC by Yedidyah Bar David
Modified: 2021-07-29 07:16 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2021-07-29 07:16:12 UTC
oVirt Team: Integration
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.