Bug 1786314

Summary: [IPI][OSP] Install fails on OpenStack with self-signed certs unless the node running the installer has the CA cert in its system trusts
Product: OpenShift Container Platform Reporter: David Sanz <dsanzmor>
Component: InstallerAssignee: Mike Fedosin <mfedosin>
Installer sub component: OpenShift on OpenStack QA Contact: David Sanz <dsanzmor>
Status: ASSIGNED --- Docs Contact:
Severity: low    
Priority: medium CC: asimonel, eduen, eparis, jappleii, juriarte, kholden, m.andre, mfedosin, pprinett, wjiang
Version: 4.3.0   
Target Milestone: ---   
Target Release: 4.6.0   
Hardware: Unspecified   
OS: Unspecified   
URL: https://issues.redhat.com/browse/OSASINFRA-1137
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description David Sanz 2019-12-24 10:56:12 UTC
Description of problem:

When installing OSP16 with self-signed certs, OSPd generates a clouds.yaml file with cacert parameter like:

clouds:
  overcloud:
    auth:
        auth_url: https://10.0.0.101:13000
        password: admin
        project_domain_name: Default
        project_name: admin
        user_domain_name: Default
        username: admin
    cacert: /etc/pki/ca-trust/source/anchors/undercloud-cacert.pem
    identity_api_version: '3'

Using this clouds.yaml generated by OSP16 installer cannot be used to install OCP 4.3:

# ./openshift-install create cluster
FATAL failed to fetch Terraform Variables: failed to load asset "Install Config": invalid "install-config.yaml" file: [platform.openstack.externalNetwork: Internal error: could not retrieve valid networks, platform.openstack.computeFlavor: Internal error: could not retrieve valid flavors, platform.openstack.trunkSupport: Internal error: could not retrieve networking extension aliases, platform.openstack.octaviaSupport: Internal error: could not retrieve service catalog] 

If cacert file is imported on the system and cacert parameter is removed from the clouds.yaml file, installer works.

Version-Release number of the following components:
# ./openshift-install version
./openshift-install v4.3.0
built from commit 93c78d09ed9e2badb4bf5dab708152fe6b3b6602
release image registry.svc.ci.openshift.org/ocp/release@sha256:4cb1574385e4dfcb9342f4041eb674b3df51e31e6294ba433ce814c1b864dc86

How reproducible:

Steps to Reproduce:
1.Install OSP16 using OSPd with self-signed SSL
2.Get clouds.yaml file generated by OSPd and use it to install OCP

Actual results:
OCP is not installed but clouds.yaml is valid and can be used to execute openstack commands

Expected results:
OCP gets clouds.yaml file and checks cacert parameter


Additional info:
Please attach logs from ansible-playbook with the -vvv flag

Comment 2 Eric Duen 2020-01-03 21:10:11 UTC
David see comment #1 for question

Comment 6 Martin André 2020-02-04 14:20:17 UTC
This is currently documented as a known limitation in the upstream docs: https://github.com/openshift/installer/blob/8c55eae/docs/user/openstack/README.md#self-signed-openstack-ca-certificates

The workaround is to add the CA cert to the trusts of the node running the installer:

sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract
 
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/director_installation_and_usage/appe-ssltls_certificate_configuration#Adding_the_Certificate_Authority_to_Clients

Comment 7 Martin André 2020-02-20 15:38:00 UTC
Re-targeting to 4.5, because it's not blocking 4.4.

Comment 8 Pierre Prinetti 2020-05-07 14:41:33 UTC
The team considers this bug as valid. Considering this bug priority and our capacity, we are deferring this bug to an upcoming sprint. If there are reasons for us to reprioritise, please let us know.

Comment 9 Pierre Prinetti 2020-05-14 14:25:50 UTC
Considering the priority assigned to this bug and our team capacity, we are deferring this bug to an upcoming sprint. Please let us know if there are reasons for us to reprioritize.