There are two tls issues currently in neutron:
A) neutron_api is doing bind mounting tls certs directly from the host and then chowning them from then container.
"Source": "/etc/pki/tls/private/ovn_neutron_client.key",
"Destination": "/etc/pki/tls/private/ovn_neutron_client.key",
And then it thinks it can chown it inside the container via the kolla script:
[root@controller-0 stdouts]# more /var/lib/kolla/config_files/neutron_api.json
...
{ "optional": true, "owner": "neutron:neutron", "path": "/etc/pki/tls/certs/ovn_neutron_client.crt", "perm": "0644"
},
{ "optional": true, "owner": "neutron:neutron", "path": "/etc/pki/tls/private/ovn_neutron_client.key", "perm": "0644"
}
What needs to happen here is that we drop the direct bind mounts, and copy in the certs via kolla. Just like galera is doing.
Tested and with this patch I correctly get a Train/OSP16 TLS everywhere
deployment with a working neutron:
Before:
(overcloud) [stack@undercloud-0 ~]$ openstack network list
HttpException: 503: Server Error for url: https://overcloud.redhat.local:13696/v2.0/networks, No server is available to handle this request.: 503 Service Unavailable
After:
(overcloud) [stack@undercloud-0 ~]$ openstack network list
(overcloud) [stack@undercloud-0 ~]$
B) The logging in the neutron_server_tls_proxy container is not persisted to the host
Before:
[root@controller-0 ~]# ls -l /var/log/containers/httpd/neutron-api/
[root@controller-0 ~]#
After:
[root@controller-0 ~]# ls -l /var/log/containers/httpd/neutron-api/
total 136
-rw-r--r--. 1 root root 400 Nov 15 17:43 error_log
-rw-r--r--. 1 root root 72784 Nov 15 17:53 neutron-api-proxy_access_ssl.log
-rw-r--r--. 1 root root 2748 Nov 15 17:43 neutron-api-proxy_error_ssl.log
[root@controller-0 ~]#
Reviewed: https:/ /review. opendev. org/694614 /git.openstack. org/cgit/ openstack/ tripleo- heat-templates/ commit/ ?id=a7db39af7cf 779e5e236c6f9b5 4c260feba24b98
Committed: https:/
Submitter: Zuul
Branch: master
commit a7db39af7cf779e 5e236c6f9b54c26 0feba24b98
Author: Michele Baldessari <email address hidden>
Date: Fri Nov 15 18:50:28 2019 +0100
Fix neutron api TLS issues
There are two tls issues currently in neutron: tls/private/ ovn_neutron_ client. key", tls/private/ ovn_neutron_ client. key",
A) neutron_api is doing bind mounting tls certs directly from the host and then chowning them from then container.
"Source": "/etc/pki/
"Destination": "/etc/pki/
"Source": "/etc/pki/ tls/certs/ ovn_neutron_ client. crt", tls/certs/ ovn_neutron_ client. crt",
"Destination": "/etc/pki/
And then it thinks it can chown it inside the container via the kolla script: controller- 0 stdouts]# more /var/lib/ kolla/config_ files/neutron_ api.json
"optional" : true,
"owner" : "neutron:neutron",
"path" : "/etc/pki/ tls/certs/ ovn_neutron_ client. crt",
"perm" : "0644"
"optional" : true,
"owner" : "neutron:neutron",
"path" : "/etc/pki/ tls/private/ ovn_neutron_ client. key",
"perm" : "0644"
[root@
...
{
},
{
}
What needs to happen here is that we drop the direct bind mounts, and copy in the certs via kolla. Just like galera is doing.
Tested and with this patch I correctly get a Train/OSP16 TLS everywhere /overcloud. redhat. local:13696/ v2.0/networks, No server is available to handle this request.: 503 Service Unavailable
deployment with a working neutron:
Before:
(overcloud) [stack@undercloud-0 ~]$ openstack network list
HttpException: 503: Server Error for url: https:/
After:
(overcloud) [stack@undercloud-0 ~]$ openstack network list
(overcloud) [stack@undercloud-0 ~]$
B) The logging in the neutron_ server_ tls_proxy container is not persisted to the host
Before: controller- 0 ~]# ls -l /var/log/ containers/ httpd/neutron- api/ controller- 0 ~]#
[root@
[root@
After: controller- 0 ~]# ls -l /var/log/ containers/ httpd/neutron- api/ api-proxy_ access_ ssl.log api-proxy_ error_ssl. log controller- 0 ~]#
[root@
total 136
-rw-r--r--. 1 root root 400 Nov 15 17:43 error_log
-rw-r--r--. 1 root root 72784 Nov 15 17:53 neutron-
-rw-r--r--. 1 root root 2748 Nov 15 17:43 neutron-
[root@
Change-Id: Ia1c22b8981fb73 5a052707516f733 13c4e5ca93c
Closes-Bug: #1852779