freezer-api haproxy ssl config not being set

Bug #1973294 reported by Daniel Reader-Powell
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
kolla-ansible
New
Undecided
Unassigned

Bug Description

What happened:

When attempting to open the disaster recovery options in horizon I receive a SSL verification error.

"Error: SSL exception connecting to https://int-cloud.sys.192.com:5000/v3/auth/tokens: HTTPSConnectionPool(host='int-cloud.sys.192.com', port=5000): Max retries exceeded with url: /v3/auth/tokens (Caused by SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897)'),)) "

What I expected to happen:

I would be able to setup and schedule some backups. This was previously working with Wallaby, but this has broken following an update to Xena.

How to reproduce it:

This may be specific to our environment as we use freeIPA to supply certificates to our services and set the following vars:

```
etcd_enable_tls: no
kolla_enable_tls_internal: "yes"
kolla_enable_tls_external: yes
kolla_admin_openrc_cacert: "/etc/pki/tls/cert.pem"
openstack_cacert: /etc/pki/tls/certs/ca-bundle.crt
kolla_enable_tls_backend: "yes"
kolla_verify_tls_backend: "yes"
kolla_tls_backend_cert: "{{ kolla_certificates_dir }}/backend-cert.pem"
kolla_tls_backend_key: "{{ kolla_certificates_dir }}/backend-key.pem"
rabbitmq_enable_tls: "yes"
```

OS:
NAME="CentOS Stream"
VERSION="8"

Kernel:
Linux controller01.sys.192.com 4.18.0-338.el8.x86_64 #1 SMP Fri Aug 27 17:32:14 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Docker version: 20.10.14

Kolla Ansible Version: 13.0.1 (stable/xena)

Here's what I think is happening. The freezer_services defined as:
```
---
freezer_services:
  freezer-api:
    container_name: freezer_api
    group: freezer-api
    enabled: true
    image: "{{ freezer_api_image_full }}"
    volumes: "{{ freezer_api_default_volumes + freezer_api_extra_volumes }}"
    dimensions: "{{ freezer_api_dimensions }}"
    haproxy:
      freezer_api:
        enabled: "{{ enable_freezer }}"
        mode: "http"
        external: false
        port: "{{ freezer_api_port }}"
      freezer_api_external:
        enabled: "{{ enable_freezer }}"
        mode: "http"
        external: true
        port: "{{ freezer_api_port }}"
  freezer-scheduler:
    container_name: freezer_scheduler
    group: freezer-scheduler
    enabled: true
    image: "{{ freezer_scheduler_image_full }}"
    volumes: "{{ freezer_scheduler_default_volumes + freezer_scheduler_extra_volumes }}"
    dimensions: "{{ freezer_scheduler_dimensions }}"
```

Are missing the tls_backend variable. If I look at another service (heat in this example) I can see that the tls_backend variable is set like so:
```
    haproxy:
      heat_api:
        enabled: "{{ enable_heat }}"
        mode: "http"
        external: false
        port: "{{ heat_api_port }}"
        listen_port: "{{ heat_api_listen_port }}"
        tls_backend: "{{ heat_enable_tls_backend }}"
```

This translates to the haproxy service config as:
```
backend heat_api_back
    mode http
    server controller01 10.xxx.xxx.xxx:8004 check check-ssl inter 2000 rise 2 fall 5 ssl verify required ca-file ca-bundle.trust.crt
    server controller02 10..xxx.xxx.xxx:8004 check check-ssl inter 2000 rise 2 fall 5 ssl verify required ca-file ca-bundle.trust.crt
    server controller03 10..xxx.xxx.xxx:8004 check check-ssl inter 2000 rise 2 fall 5 ssl verify required ca-file ca-bundle.trust.crt
```

But the freezer-api is set as:
```
backend freezer_api_back
    mode http
    server controller01 10..xxx.xxx.xxx:9190 check inter 2000 rise 2 fall 5
    server controller02 10..xxx.xxx.xxx:9190 check inter 2000 rise 2 fall 5
    server controller03 10..xxx.xxx.xxx:9190 check inter 2000 rise 2 fall 5
```

I also note that the freezer-scheduler config is missing the os_ca_cert variable. e.g.
```
os_cacert=/etc/pki/tls/certs/ca-bundle.crt
```

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.