Mas*_*597 8 landscape juju openstack maas openstack-autopilot
使用当前 Landscape 的“OpenStack Beta”选项在我的 MAAS 设置上部署 OpenStack。我完成了 98%，“配置可用区”失败了 1 次。我的设置使用了 KVM、Open vSwitch，我目前使用 Ceph 进行对象和块存储。当我查看横向机器上的/var/log/landscape/job-handler-1.log时，看到了 100 多个关于以下内容的错误：
2015-03-05 21:18:38 INFO root RetryingCall for '_get_nova_info' 失败，再尝试 103 次：2015-03-05 21:18:38 INFO root 回溯：：缺少 4 个新星计算单元
/usr /lib/python2.7/threading.py:783:__bootstrap
/usr/lib/python2.7/threading.py:810:__bootstrap_inner
/usr/lib/python2.7/threading.py:763:run
--- <此处捕获异常> ---
/usr/lib/python2.7/dist-packages/twisted/python/threadpool.py:191:_worker
/usr/lib/python2.7/dist-packages/twisted/python/context. py:118:callWithContext
/usr/lib/python2.7/dist-packages/twisted/python/context.py:81:callWithContext
/usr/lib/python2.7/dist-packages/storm/twisted/transact.py: 76:_包裹
/opt/canonical/landscape/canonical/landscape/model/openstack/jobs.py:751:_get_nova_info
注意：jobs.py 中的行号是关闭的，因为我添加了一些用于调试的打印语句。这是 _get_nova_info() 函数中#741 行附近的断言（如果没记错的话），是的，我正在使用景观 ppa 中最新版本的景观，以确保可信。
所以我修改了/opt/canonical/landscape/canonical/landscape/model/openstack/jobs.py的_get_nova_info()函数来打印出nova_compute_hostnames的长度，我得到了零。因此，我将其追入/opt/canonical/landscape/canonical/landscape/model/openstack/region.py的get_nova_compute_hostnames()并发现self.juju_environment.get_computer_ids().count()也为零。所以我添加了一个对self.juju_environment.has_computers()的调用并得到了false。然后我跑了self.juju_environment.get_juju_home()并得到/var/lib/landscape/juju-homes/20。（是的，这是我第二次重建景观盒的第 20 次尝试，我已经这样做了一段时间）。所以我利用上面提到的 juju home运行了juju status并且一切看起来都很好。所有 5 台机器和服务都已启动，没有挂起或错误状态。（包括 4 个 nova-compute 节点）有什么想法吗？我对景观、MAAS、JUJU 和 python 有点陌生，所以我的调试有点慢。
根据请求，我有 2 个日志（尽管我的家现在是 #23） juju status和broker.log。我想我现在知道根据下面的 broker.log 片段我的问题是什么。（感谢 dpb 指出我在那里）我的 MAAS 机器将 DHCP 地址分配给我的横向 LXC，但我的横向 LXC 不在 MAAS 控制的 DNS 中，因为它不是由 MAAS 提供的。因此，已配置的计算机无法按名称连接到景观服务器。
所以这让我想到了一个相关的问题，是否有一种好方法可以让 MAAS 使用未配置（或在 MAAS 控制下）的机器自动更新 DNS？如果不是，我将不得不在我的 DHCP 范围之外给它一个静态 IP 并手动设置 DNS。
2015-03-06 17:09:50,665 INFO [MainThread] Broker 启动配置 /etc/landscape/client.conf
2015-03-06 17:09:52,382 INFO [MainThread] 开始与https://landscape 的紧急消息交换/消息系统。
2015-03-06 17:09:52,389 错误 [PoolThread-twisted.internet.reactor-1] 在https://landscape/message-system联系服务器时出错。
回溯（最近一次调用）：
文件“/usr/lib/python2.7/dist-packages/landscape/broker/transport.py”，第71行，交换
message_api）
文件“/usr/lib/python2.7/ dist-packages/landscape/broker/transport.py"，第 45 行，在 _curl
headers=headers、cainfo=self._pubkey、curl=curl))
文件“/usr/lib/python2.7/dist-packages/landscape/lib/fetch.py”，第 109 行，在 fetch
raise PyCurlError(e.args[0], e.args 1 )
PyCurlError: Error 6: could无法解析主机：横向
2015-03-06 17:09:52,390 INFO [MainThread] 消息交换失败。
2015-03-06 17:09:52,391 INFO [MainThread] 消息交换在 0.01 秒内完成。
我的设置有点受限，因为我只有 6 台机器（5 个节点和 1 个控制器）来展示 OpenStack/Landscape 的功能，所以我不能使用专门的机器来处理景观。我在我的 MAAS 控制器上的LXC中使用了Landscape-server-quickstart，所以我可以快速地将它吹走并重新开始。
所以我取消了景观设置并将 LXC 设置为静态 IP，然后修改了 DNS（由 MAAS 控制）为我的景观服务器提供静态 DNS 条目。然后我使用上面提到的 Landscape-server-quickstart 方法在 LXC 上安装 Landscape Dedicated Server。
在重新安装之后（主要是为了清除我所有的调试混乱），我终于能够通过横向安装 OpenStack。谢谢。
“缺少 N 个 nova 计算单元”消息与注册回景观的景观客户端代理有关，请检查/var/log/landscape/broker.log缺少的单元。
正如您所正确识别的那样，如果 LDS（Landscape Dedicated Server）安装到 OpenStack 所在的同一 MAAS 上，那么事情会最顺利，主要是因为网络路由和 DNS。然而，有效拓扑以及网络之间的路由等存在无数的变化。
关于尝试的一些建议，请全部阅读。最后，您需要确定您的部署拓扑：
为了进行测试，将 LDS 部署到您的 openstack 所在的同一个 MAAS——只是为了检查那里是否正常工作。使用openstack-install工具，或者直接使用 Landscape-dense-maas捆绑包和 juju-quickstart 来实现这一点。
正如您所说，您的客户需要能够联系 LDS。如果他们可以通过 IP 路由到部署 LDS 的位置，您可以拆除 openstack 安装，更改 apache 服务器名称设置，然后重试。 juju set apache2 servername=IP_ADDRESS。执行此操作后，按照 juju debug-log 进行操作，确保一切正常，并确保您可以浏览到位于https://IP_ADDRESS/ URL 的 LDS GUI。