初次接觸 OpenStack ，之前按照官方文檔安裝了一遍，期間碰到了幾個問題，而且是由於官網給出的配置錯誤導致的，在此總結記錄一下。
首先要說明，解決問題最根本的方法就是：看日誌，看日誌，看日誌，而且 OpenStack 各組件之間有調用關係，需要查看多個日誌來定位問題所在！
Horizon 安裝後，Web 無法訪問，報錯爲 500 Internal Server Error
Horizon使用的是 apache 服務，新版本已經沒有了horizon的log，全部整合到了httpd中，所以在控制節點上查看相關日誌：tail -f /var/log/httpd/error_log，顯示如下內容（只摘出了關鍵報錯）：
File "/usr/share/openstack-dashboard/openstack_dashboard/settings.py", line 345, in <module>
'.secret_key_store'))
File "/usr/lib/python2.7/site-packages/horizon/utils/secret_key.py", line 69, in generate_or_read_from_file
key = read_from_file(key_file)
File "/usr/lib/python2.7/site-packages/horizon/utils/secret_key.py", line 51, in read_from_file
with open(key_file, 'r') as f:
IOError: [Errno 13] Permission denied: '/usr/share/openstack-dashboard/openstack_dashboard/local/.secret_key_store'
這裏提示權限拒絕
定位文件，查看權限：
[root@controller local]# pwd
/usr/share/openstack-dashboard/openstack_dashboard/local
[root@controller local]# ll -a
total 32
drwxr-xr-x. 4 root root 4096 May 3 23:47 .
drwxr-xr-x. 18 root root 4096 May 3 21:27 ..
drwxr-xr-x. 2 root root 96 May 3 21:27 enabled
-rw-r--r--. 1 root root 0 Jan 23 19:29 __init__.py
-rw-r--r--. 2 root root 155 Jan 23 21:46 __init__.pyc
-rw-r--r--. 2 root root 155 Jan 23 21:46 __init__.pyo
drwxr-xr-x. 2 root root 236 May 3 21:27 local_settings.d
lrwxrwxrwx. 1 root root 53 May 3 21:27 local_settings.py -> ../../../../../etc/openstack-dashboard/local_settings
-rw-r-----. 1 root root 1256 May 3 23:47 local_settings.pyc
-rw-r--r--. 1 root root 4276 Jan 23 21:46 local_settings.pyo
-rw-------. 1 root root 64 May 3 22:34 .secret_key_store # 這裏看到文件權限是 0600
-rw-r--r--. 1 root root 0 May 3 22:34 _usr_share_openstack-dashboard_openstack_dashboard_local_.secret_key_store.lock
嘗試修改文件權限爲 777，再次訪問 Web 界面，看到日誌文件中如下報錯：
FilePermissionError: Insecure permissions on key file /usr/share/openstack-dashboard/openstack_dashboard/local/.secret_key_store, should be 0600.
但是修改前的文件權限確實是 0600 ，可見不是權限的問題；恢復原來的權限。
……（長久 Google 未果），也嘗試過刪除文件的方法，但都未能奏效。
於是，自己動手豐衣足食，因爲 OpenStack 是用 Python 寫的，我恰好略懂一些 Python 皮毛，查看報錯文件中的 Python 文件：
File "/usr/share/openstack-dashboard/openstack_dashboard/settings.py", line 345, in <module>
'.secret_key_store'))
查看此文件的 345 行附近：
334 # Ensure that we always have a SECRET_KEY set, even when no local_settings.py
335 # file is present. See local_settings.py.example for full documentation on the
336 # horizon.utils.secret_key module and its use.
337 if not SECRET_KEY:
338 if not LOCAL_PATH:
339 LOCAL_PATH = os.path.join(os.path.dirname(os.path.abspath(__file__)),
340 'local')
341
342 # pylint: disable=ungrouped-imports
343 from horizon.utils import secret_key
344 SECRET_KEY = secret_key.generate_or_read_from_file(os.path.join(LOCAL_PATH,
345 '.secret_key_store'))
這裏註釋寫的很明白：需要從local_settings.py文件中讀取SECRET_KEY，如果沒有的話，就調用模塊from horizon.utils import secret_key來生成。於是查看初始的local_settings.py，找到相關說明：
# Set custom secret key:
# You can either set it to a specific value or you can let horizon generate a
# default secret key that is unique on this machine, e.i. regardless of the
# amount of Python WSGI workers (if used behind Apache+mod_wsgi): However,
# there may be situations where you would want to set this explicitly, e.g.
# when multiple dashboard instances are distributed on different machines
# (usually behind a load-balancer). Either you have to make sure that a session
# gets all requests routed to the same dashboard instance or you set the same
# SECRET_KEY for all of them.
SECRET_KEY='05f67612642d2bc1bf9a'
這裏的註釋說明：SECRET_KEY是每臺機器唯一的，可以手動指定，也可以讓horizon來生成；很顯然我這裏是後者，自動生成的，但是無法使用，提示權限錯誤。
繼續查看下一個錯誤，是讀取文件，跳過該錯誤，直接查看讀取文件的函數/usr/lib/python2.7/site-packages/horizon/utils/secret_key.py，51 行報錯：
46 def read_from_file(key_file='.secret_key'):
47 if (os.stat(key_file).st_mode & 0o777) != 0o600:
48 raise FilePermissionError(
49 "Insecure permissions on key file %s, should be 0600." %
50 os.path.abspath(key_file))
51 with open(key_file, 'r') as f:
52 key = f.readline()
53 return key
查看不到有什麼異常問題。放棄！所以，只能曲線救國了。。。
解決方法：
前面提到需要從local_settings.py文件中讀取SECRET_KEY，那我直接在文件裏面指定SECRET_KEY就好了啊！
於是，查看.secret_key_store中的內容，將其寫入local_settings.py中：
[root@controller local]# pwd
/usr/share/openstack-dashboard/openstack_dashboard/local
[root@controller local]# more .secret_key_store
GUM4T1AwQbF536JpKNQk10Vq0EpOIIudUQ0hpoAPBdTvDkgvUuuuGagAE4xajUVx
[root@controller local]# echo "SECRET_KEY='GUM4T1AwQbF536JpKNQk10Vq0EpOIIudUQ0hpoAPBdTvDkgvUuuuGagAE4xajUVx'" >> local_settings.py
重啓服務systemctl restart httpd，頁面正常，可以顯示出來了（正常流程應該是可以訪問了，但是我這裏還是不行，出現了新的錯誤，見下！！！）。
（這個問題可能是由於 Python 讀取 Linux 系統中文件有權限問題？希望有大佬解惑）
The requested URL /auth/login/ was not found on this server.
第一個問題中，500 的錯誤解決了，又報出來一個 無法找到頁面 orz…
官方文檔中說，通過http://controller/dashboard進行訪問 Web 端
這次是 404 錯誤，顯然服務已經正常啓動，所以 log 中也查看不到有錯誤日誌，但是看起來鏈接跳轉的不對（這是事後結論） ：
查看 httpd 中 dashboard 的配置文件vim /etc/httpd/conf.d/openstack-dashboard.conf：
WSGIScriptAlias /dashboard /usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi
Alias /dashboard/static /usr/share/openstack-dashboard/static
<Directory /usr/share/openstack-dashboard/openstack_dashboard/wsgi>
Options All
AllowOverride All
Require all granted
</Directory>
<Directory /usr/share/openstack-dashboard/static>
Options All
AllowOverride All
Require all granted
</Directory>
發現其中定義了兩個別名，意思就是訪問http://10.1.1.128/dashboard會重定向到django.wsgi文件，網站的靜態文件在/dashboard/static中，但是提示 404 錯誤的 URL 是 http://10.1.1.128/auth/login/?next=/dashboard/如上圖，經過查看，static 文件夾下也確實有 auth/login相關的文件。
修改鏈接，嘗試訪問：http://10.1.1.128/dashboard/auth/login/?next=/dashboard/，發現可以訪問，只是缺少了 CSS 樣式：
可以發現這個問題是由於 Web 路徑錯誤導致的。
解決辦法：
方法一：修改local_settings.py文件，添加網站根目錄WEBROOT = '/dashboard' ，重啓服務，修復問題。
pwd
/usr/share/openstack-dashboard/openstack_dashboard/local
echo "WEBROOT = '/dashboard'" >> local_settings.py
systemctl restart httpd
方法二：修改 httpd 配置文件，將別名中的/dashboard刪除，然後通過http://10.1.1.128/直接進行訪問！
# 刪除配置文件的 dashboard，但要保留 /
WSGIScriptAlias / /usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi
Alias /static /usr/share/openstack-dashboard/static
RuntimeError: Unable to create a new session key. It is likely that the cache is unavailable.
Web 界面可以登錄進來了，但是輸入域，用戶名，密碼之後，無法登錄進去！
查看 log：
[Sun May 04 23:42:22.839562 2020] [:error] [pid 37959] RuntimeError: Unable to create a new session key. It is likely that the cache is unavailable.
提示SESSION相關的問題。。。
解決辦法：
原文：https://www.cnblogs.com/yaohong/p/7351543.html
把/etc/openstack-dashboard/local_settings中的：
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'修改爲
SESSION_ENGINE = 'django.contrib.sessions.backends.file'，重啓服務，問題解決。
虛擬機異常掉電後，計算節點掉線…
通過命令行啓動了一個實例，然而一直顯示在調度中，一開始以爲虛擬機性能不夠，等了 10 分鐘還顯示調度中後，事情似乎不簡單了 -，-：
# nova list 查看實例信息
+--------------------------------------+-------------------+--------+------------+-------------+----------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+-------------------+--------+------------+-------------+----------+
| 33d59558-8ed5-47f0-914c-4830e963b2fb | my-first-instance | BUILD | scheduling | NOSTATE | |
+--------------------------------------+-------------------+--------+------------+-------------+----------+
因爲我只部署了一個計算節點，基本不存在調度的問題，檢查了一下計算節點的狀態：
openstack compute service list --service nova-compute
+----+--------------+-----------------------+------+---------+-------+----------------------------+
| ID | Binary | Host | Zone | Status | State | Updated At |
+----+--------------+-----------------------+------+---------+-------+----------------------------+
| 5 | nova-compute | localhost.localdomain | nova | enabled | down | 2020-05-03T12:35:23.000000 |
| 6 | nova-compute | compute1 | nova | enabled | down | 2020-05-04T03:33:44.000000 |
+----+--------------+-----------------------+------+---------+-------+----------------------------+
嗯，計算節點宕機了。
查看計算節點的 log 信息tailf /var/log/nova.log：
AccessRefused: (0, 0): (403) ACCESS_REFUSED - Login was refused using authentication mechanism AMQPLAIN. For details see the broker logfile.
錯誤信息顯示一直在重連隊列服務，也就是 rabbitmq，一直報登錄失敗的錯誤。
檢查配置/etc/nova/nova.conf無誤後，到控制節點查看 rabbitmq 的日誌信息：
Error on AMQP connection <0.3350.0> (10.1.1.128:36550 -> 10.1.1.128:5672, state: starting):
AMQPLAIN login refused: user 'openstack' - invalid credentials
控制節點收到了大量的連接請求，但是無法連接成功，提示用戶openstack不正確。
解決方法：
提示用戶不正確，那就重新創建一次用戶唄：
rabbitmqctl add_user openstack RABBIT_PASS
rabbitmqctl set_permissions openstack ".*" ".*" ".*"
之後檢查計算節點，已經上線。（問題出現的原因尚不得知，我只是前一天晚上異常關機了而已……）
ResourceProviderRetrievalFailed: Failed to get resource provider with UUID 4d252eb7-2eb6-4622-99c8-4b5ef0e0de04
繼續創建實例，又有了新問題！
這次我直接開了一個窗口，通過tail -f /var/log/nova.log實時查看日誌信息……
上述問題解決辦法，修改 placement 配置文件/etc/httpd/conf.d/00-nova-placement-api.conf，添加以下內容：
出處：https://ask.openstack.org/en/question/103325/ah01630-client-denied-by-server-configuration-usrbinnova-placement-api/
<Directory /usr/bin>
<IfVersion >= 2.4>
Require all granted
</IfVersion>
<IfVersion < 2.4>
Order allow,deny
Allow from all
</IfVersion>
</Directory>
No DHCP agents available
創建一個實例好難啊🤦♂️。
https://ask.openstack.org/en/question/108855/no-dhcp-agents-available/
https://www.dazhuanlan.com/2019/10/21/5dad6a15d7d38/
通過openstack network agent list檢查發現我的網絡服務基本都不正常。
通過上面參考鏈接，得出一個結論：
官網文檔安裝網絡服務 Neutron 那一節中/etc/neutron/plugins/ml2/ml2_conf.ini這個配置文件有點問題，這裏留空後，網絡服務就異常了：
經過查閱百度，我這裏最終填上了flat（我創建的是最簡單的二層網絡）
修改完配置文件後，再次查看網絡服務就正常了 orz，控制節點的網絡服務索性全部重啓了一遍systemctl restart neutron-server neutron-linuxbridge-agent neutron-dhcp-agent neutron-metadata-agent。記得計算節點也要修改，修改配置文件後要重啓服務systemctl restart neutron-linuxbridge-agent.service。
具體爲何異常，我也不懂啊，等以後深入學習了 Neutron 之後，再來看看吧。
實例啓動後，無法從硬盤啓動 Booting from Hard Disk… GRUB
解決辦法：修改計算節點的配置文件
出處：https://ask.openstack.org/en/question/101928/instance-get-stuck-when-booting-grub/
# 在計算節點修改配置文件 /etc/nova/nova.conf
[libvirt]
virt_type = qemu
cpu_mode = none
# 修改後重啓計算節點服務
systemctl restart libvirtd.service openstack-nova-compute
問題原因：這是嵌套虛擬化的問題，需要修改計算節點的nova.conf。報錯的原因在於 openstack 的 libvirt 默認 hyper 是 kvm 而不是純 qemu ，redhat 系列的 linux 下 kvm 不支持嵌套虛擬化。這種修改方式只適用於做實驗學習（忘了從哪看到的一句話
重啓實例，可以看到實例啓動成功！！！
通過 SSH 也可以登錄到實例上：
如果有其他問題，會繼續更新……