OpenStack趟坑之rocky版

OpenStack可以说是我学linux来配置花费时间最长的软件，没有之一，由于其配置步骤较多，所以出错的几率也会增大。rocky版作为18年8月新出的版本，官方文档上也是有很多的不足。

配置keystone组件

配置数据库时，使用以下命令进行数据库用户授权：

MariaDB [(none)]> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' \
IDENTIFIED BY 'KEYSTONE_DBPASS';
MariaDB [(none)]> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' \
IDENTIFIED BY 'KEYSTONE_DBPASS';

配置/etc/keystone/keystone.conf完成后，使用su -s /bin/sh -c "keystone-manage db_sync" keystone 同步数据库后，回车后没有在屏幕报错，以为同步成功后的我执行了下一步，在最后验证时直接报http：500错误，查看/var/log/keystone/keystone.log 发现报错为: ACCESS denied,在连接数据库时权限被拒绝，这时候我们可以判断是数据库的用户授权的问题,这时候我们回到数据库加入了 以下命令(controller node 和compute node的IP地址)：

MariaDB [(none)]> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'10.0.0.11' \
IDENTIFIED BY 'KEYSTONE_DBPASS';
MariaDB [(none)]> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'10.0.0.31' \
IDENTIFIED BY 'KEYSTONE_DBPASS';

刷新授权后，重新进行初始化数据库，查看日志发现INFO…，查看keystone数据库,发现数据已经同步，这时候执行初始化数据库的下一步操作，如果直接验证，会报http:400错误 ，重新执行以下命令就可以解决:

# keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone
# keystone-manage credential_setup --keystone-user keystone --keystone-group keystone

# keystone-manage bootstrap --bootstrap-password ADMIN_PASS \
  --bootstrap-admin-url http://controller:5000/v3/ \
  --bootstrap-internal-url http://controller:5000/v3/ \
  --bootstrap-public-url http://controller:5000/v3/ \
  --bootstrap-region-id RegionOne

但不是所有机器都需要执行IP单独授权，只是单独的机器会出现问题。所以在同步数据后一定要去查看数据是否同步成功，这样会省去之后的很多麻烦。

keystone在验证时，有下面的命令：

$ openstack --os-auth-url http://controller:33573/v3 \
  --os-project-domain-name Default --os-user-domain-name Default \
  --os-project-name admin --os-username admin token issue

执行完成后报错，我们将controller的端口改成：5000就可以了。注：现在官方文档已改正。

nova组件

在最后dashboard执行时，发现我们的实例控制台不能出现，因为在验证nova时执行openstack compute service list ,回显为:

+----+--------------------+------------+----------+---------+-------+----------------------------+
| Id | Binary             | Host       | Zone     | Status  | State | Updated At                 |
+----+--------------------+------------+----------+---------+-------+----------------------------+
|  1 | nova-scheduler     | controller | internal | enabled | up    | 2016-02-09T23:11:15.000000 |
|  5 | nova-conductor     | controller | internal | enabled | up    | 2016-02-09T23:11:16.000000 |
|  8 | nova-compute       | compute1   | nova     | enabled | up    | 2016-02-09T23:11:20.000000 |
+----+--------------------+------------+----------+---------+-------+----------------------------+

而官方文档验证回显为：

$ openstack compute service list

+----+--------------------+------------+----------+---------+-------+----------------------------+
| Id | Binary             | Host       | Zone     | Status  | State | Updated At                 |
+----+--------------------+------------+----------+---------+-------+----------------------------+
|  1 | nova-consoleauth   | controller | internal | enabled | up    | 2016-02-09T23:11:15.000000 |
|  2 | nova-scheduler     | controller | internal | enabled | up    | 2016-02-09T23:11:15.000000 |
|  3 | nova-conductor     | controller | internal | enabled | up    | 2016-02-09T23:11:16.000000 |
|  4 | nova-compute       | compute1   | nova     | enabled | up    | 2016-02-09T23:11:20.000000 |
+----+--------------------+------------+----------+---------+-------+----------------------------+

我们查看controller node 文档时发现：

# systemctl start openstack-nova-api.service \
  openstack-nova-scheduler.service openstack-nova-conductor.service \
  openstack-nova-novncproxy.service

没有启动openstack-nova-consoleauth服务，在我们执行systemctl start openstack-nova-consoleauth后，刷新界面即可。

dashboard组件

在修改/etc/openstack-dashboard/local_settings 之后，重启httpd服务，发现服务起不来，看日志报错后发现是ALLOWED_HOSTS = ['one.example.com', 'two.example.com'] 出现的问题，修改为ALLOWED_HOSTS = ['*',] 重启httpd服务即可。

基本上也就这么多了，觉得最省时间的方法就是做完一步之后，验证之后在进行下一步，如果验证之后发现结果错误，就不要进行下一步了，解决完之后在进行下一步骤，因为之后的很多步骤都是依赖上一步的。