Bug 1986118

Summary: Deprovisioning failing with SSL error when ironic operating on external network
Product: OpenShift Container Platform Reporter: Zane Bitter <zbitter>
Component: Bare Metal Hardware ProvisioningAssignee: Tomas Sedovic <tsedovic>
Bare Metal Hardware Provisioning sub component: ironic QA Contact: Amit Ugol <augol>
Status: CLOSED DUPLICATE Docs Contact:
Severity: unspecified    
Priority: unspecified CC: imain, sdasu
Version: 4.9   
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-26 17:49:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screenshot of IPA console none

Description Zane Bitter 2021-07-26 17:30:12 UTC
Created attachment 1806021 [details]
screenshot of IPA console

When the Provisioning CR is configured to have IPA communicate to Ironic over the external network - either because the Provisioning network is disabled, or because the VirtualMediaViaExternalNetwork flag is set - CBO does not generate the SSL certificate for ironic using the correct IP address (which for now should be all of the IP addresses of the master nodes), but instead just uses localhost for the address.

Since hostname verification is disabled in IPA, this shouldn't pose an obstacle, and indeed inspection and provisioning works. However, deprovisioning seems not to, at least in the case of VirtualMediaViaExternalNetwork being true. It is possible that the same issue also occurs when the Provisioning network is disabled.

(Setting the component to ironic for now because it appears to be behaving inconsistently across different operations, but the ultimate fix might be in CBO or somewhere else.)

Comment 1 Zane Bitter 2021-07-26 17:49:42 UTC

*** This bug has been marked as a duplicate of bug 1985483 ***