Multi-node OpenStack Charms Deployment Guide 0.0.1.dev223-12--OpenStack configuration after openstack failure

Contents:
Section 1 Multi-node OpenStack Charms Deployment Guide 0.0.1.dev223–1--OpenStack Charms Deployment Guide
Section 2 Multi-node OpenStack Charms Deployment Guide 0.0.1.dev223–2-Install MAAS

Section 3 Multi-node OpenStack Charms Deployment Guide 0.0.1.dev223–3-Install Juju

Section 4 Multi-node OpenStack Charms Deployment Guide 0.0.1.dev223–4-Install openstack

Section 5 Multi-node OpenStack Charms Deployment Guide 0.0.1.dev223–5--Make the bundle install openstack

Section 6 Multi-node OpenStack Charms Deployment Guide 0.0.1.dev223–6--Configure vault and set the life cycle of digital certificates

Section 7 Multi-node OpenStack Charms Deployment Guide 0.0.1.dev223–7--juju Offline deployment of bundles

Section 8 Multi-node OpenStack Charms Deployment Guide 0.0.1.dev223–8--Configure OpenStack

Section 9 Multi-node OpenStack Charms Deployment Guide 0.0.1.dev223–9--Network Topology

Section 10 Multi-node OpenStack Charms Deployment Guide 0.0.1.dev223–10–OpenStack Highly Available Infrastructure Practical

Section 11 Multi-node OpenStack Charms Deployment Guide 0.0.1.dev223–11–Access Juju Dashboard

After redeploying openstack-base70 for a long time, I did not configure it. Before the Spring Festival, I thought about the configuration, and then ran k8s on it. Unfortunately, after source openrcv3_project, something went wrong:

source openrcv3_project
echo $OS_USERNAME
admin
openstack endpoint list --interface admin
Failed to discover available identity versions when contacting https://10.0.2.81:5000/v3. Attempting to parse version from URL.
SSL exception connecting to https://10.0.2.81:5000/v3/auth/tokens: HTTPSConnectionPool(host=‘10.0.2.81’, port=5000): Max retries exceeded with url: /v3/auth/tokens (Caused by SSLError(SSLError(“bad handshake: Error([(‘SSL routines’, ‘tls_process_server_certificate’, ‘certificate verify failed’)],)”,),))

Source openrc again:

source openrc
openstack endpoint list --interface admin
Could not find a suitable TLS CA certificate bundle, invalid path: /tmp/root-ca.crt

I was a little confused at first, thinking it was necessary to do TLS configuration, but there were problems with the configuration several times, and the configuration failed.

After being confused for a few days, I went to the forum to ask questions. The respondent said that I hope I will post bundle.yaml to him.

After posting, the panelist replied that your OS_CACERT=/home/ubuntu/snap/openstackclients/common/root-ca.crt, not in /tmp/root-ca.crt

At that time, I was even more confused. Didn't the documents I read say that the generated root certificate is in /tmp/root-ca.crt?

Then I looked at openrc again and found no special problems.

Suddenly I discovered how the version of openstack base has changed to openstack base#72, and the author has always deployed #70.

Later, again directly deployed bundle openstack-base # 72, in juju run-action --wait vault/leader 'generate-root-ca'front, and will remove /root/snap/openstackclient/common/root-ca.crt /tmp/root-ca.crt, then juju run-action --wait vault /leader'generate-root-ca', I found that the root-ca.crt root certificate file was not generated in the /tmp directory, but in /root/snap/openstackclient/common/root-ca.crt, again source openrc, smoothly Successful deployment of openstack

openstack endpoint list --interface admin
+----------------------------------+-----------+--------------+--------------+---------+-----------+------------------------------------------+
| ID                               | Region    | Service Name | Service Type | Enabled | Interface | URL                                      |
+----------------------------------+-----------+--------------+--------------+---------+-----------+------------------------------------------+
| 075e5dbf0bf94c99b1863441ce7cab42 | RegionOne | swift        | object-store | True    | admin     | https://10.0.2.103:443/swift             |
| 2a91f454e99c47bbae6959be815e4f76 | RegionOne | cinderv2     | volumev2     | True    | admin     | https://10.0.2.110:8776/v2/$(tenant_id)s |
| 522bdd0accc64aeba73d1ad9414765da | RegionOne | s3           | s3           | True    | admin     | https://10.0.2.103:443/                  |
| 5763f522530145ed90513f97fd734fdd | RegionOne | glance       | image        | True    | admin     | https://10.0.2.96:9292                   |
| 5dcf573397954218917df491e7f868b9 | RegionOne | keystone     | identity     | True    | admin     | https://10.0.2.101:35357/v3              |
| a17a3f32438640f68dfce72763390765 | RegionOne | neutron      | network      | True    | admin     | https://10.0.2.113:9696                  |
| daaa222120dc4ed2bbc7341590a3acdb | RegionOne | placement    | placement    | True    | admin     | https://10.0.2.99:8778                   |
| dfab9da33a974dc1b15228a18fac90c7 | RegionOne | cinderv3     | volumev3     | True    | admin     | https://10.0.2.110:8776/v3/$(tenant_id)s |
| f4b5e242719a48088df20621dea5d643 | RegionOne | nova         | compute      | True    | admin     | https://10.0.2.105:8774/v2.1             |
+----------------------------------+-----------+--------------+--------------+---------+-----------+------------------------------------------+

It seems that in the bundle, juju run-action --wait vault/leader 'generate-root-ca'after execution , the generated root certificate file directory has changed.

Compare openrc:

openstack-base#70:

if [ ! -z $JUJU_MODEL ]; then
  _juju_model_arg="-m $JUJU_MODEL"
fi
_keystone_major_version=$(juju status $_juju_model_arg keystone --format yaml| \
    awk '/^    version:/ {print $2; exit}' | cut -f1 -d\.)
_keystone_preferred_api_version=$(juju config $_juju_model_arg keystone preferred-api-version)

_root_ca=/tmp/root-ca.crt
juju run $_juju_model_arg --unit vault/leader 'leader-get root-ca' > /tmp/root-ca.crt 2>/dev/null

if [ $_keystone_major_version -ge 13 -o \
     "$_keystone_preferred_api_version" = '3' ]; then
    echo Using Keystone v3 API
    . $(dirname ${BASH_SOURCE[0]})/openrcv3_project
else
    echo Using Keystone v2.0 API
    . $(dirname ${BASH_SOURCE[0]})/openrcv2
fi

openstack-base#72:

if [ ! -z $JUJU_MODEL ]; then
  _juju_model_arg="-m $JUJU_MODEL"
fi
_keystone_major_version=$(juju status $_juju_model_arg keystone --format yaml| \
    awk '/^    version:/ {print $2; exit}' | cut -f1 -d\.)
_keystone_preferred_api_version=$(juju config $_juju_model_arg keystone preferred-api-version)

# The per user snap data directory is not created until first execution of snap
openstack --version 2>&1 > /dev/null || true

if [ -d ~/snap/openstackclients/common/ ]; then
  # When using the openstackclients confined snap the certificate has to be
  # placed in a location reachable by the clients in the snap.
  _root_ca=~/snap/openstackclients/common/root-ca.crt
else
  _root_ca=/tmp/root-ca.crt
fi
juju run $_juju_model_arg --unit vault/leader 'leader-get root-ca' > $_root_ca 2>/dev/null

if [ $_keystone_major_version -ge 13 -o \
     "$_keystone_preferred_api_version" = '3' ]; then
    echo Using Keystone v3 API
    . $(dirname ${BASH_SOURCE[0]})/openrcv3_project
else
    echo Using Keystone v2.0 API
    . $(dirname ${BASH_SOURCE[0]})/openrcv2
fi

It seems source openrcto use /tmp/root-ca.crt when setting environment variables, but when executing bundle openstack-base, the generated root certificate is in the /root/snap/openstackclient/common/root-ca.crt directory , So the source fails.

Guess you like

Origin blog.csdn.net/m0_49212388/article/details/113929799