问题标签 [rdo]

当我使用 packstack 安装 openstack Queens allinone 时，它​​卡在了：

我发现上面提到的日志，最后一行似乎没有帮助：

我还转到 puppet 运行文件并在那里找到一些警告：

有什么问题？我的基本设置步骤和环境如下：

CentOS-7-x86_64-Minimal-1611：8 核和 16GB 内存。

在 GCP 控制台中，我按照本教程安装了带有 RDO 的 OpenStack - https://www.rdoproject.org/install/packstack/。

我想从其他网络访问它。但我什至无法从我的 VM 控制台访问仪表板。如果我点击curl -v [internal_ip]/dashboard，我会得到正确的响应。但如果我打curl -v [external_ip]/dashboard，我什么也得不到：

如果我什至不能使用 VM 控制台访问外部 IP，那么我绝对不能从我的机器访问，这是我的目标。

为什么我的 GCP VM 无法使用外部 IP 获取仪表板？

我正在编写一个试图解析Recipients 的函数。起初，我主要是在调试模式下进入代码并查看 VBE Locals 窗口中的变量。我正要得出结论，该Recipient.Resolve()方法是无用的，因为我的Recipient对象和它们各自的对象AddressEntry是在调用方法之后立即设置的Recipients.Add（NameSpace.CreateRecipient如果成功解决，否则<The operation failed.>在 VBE Locals 窗口中将属性设置为错误）。

1）从我的测试来看，Recipients.Add和NameSpace.CreateRecipient方法给出了相同的结果，但它们是否完全相同？

在这里，它说

未解析的条目是尚未具有条目标识符或 PR_ENTRYID (PidTagEntryId) 属性的条目。

问题是，当找到该属性时，该Resolved属性已设置为True，并且Recipient.EntryID+Recipient.AddressEntry.ID也已设置。但后来，我意识到当我Recipient在 Locals 中扩展我的对象时，它们才被解析，因为在这样做之前，Recipient.Name仍然是Name用于搜索的，而不是解析的Recipient.AddressEntry.Name。

2) 这种在 VBE Locals 窗口中扩展变量的正常行为Recipient似乎可以解决它？

查看通讯簿 > 工具 > 选项... > 寻址我也开始了解到，在我的情况下，解决过程目前是这样的：

• 首先，搜索通用地址列表 (GAL) 通讯簿（不一定要完全匹配，但Name用作方法参数的每个部分都必须在Display Name预期结果中）
• 如果未找到（例如，如果LASTNAME FirstName (Subsidiary Company Name)在条目Display Name类似LASTNAME FirstName (Holding Company Name)或有多个结果时使用（例如同音词或匹配的联系人组）），则解析回退到联系人通讯簿（本地 Outlook 个人通讯簿或 PAB）中的搜索)
• 搜索联系人，并且规则似乎相同（例如如果有像FirstName LASTNAME+这样的重复项LASTNAME FirstName，则解析将失败）

我已经看到了这一切：

• 解析收件人姓名
• IAddrBook::ResolveName
• 地址簿限制
• PidTagAnr 规范属性
• PidTagAbSearchPath 规范属性

3) 我对 MAPI 还不是很流利，所以与我观察到的相比，我无法理解它所描述的过程：它是如何工作的以及如何涉及PR_ANR和PR_AB_SEARCH_PATH属性？

4) 我知道我不应该使用PR_AB_SEARCH_PATH它，因为它是保留给 MAPI 使用的，但它的值是什么样的？它是容器 ID 的排序数组吗？

5) 有没有办法以编程方式更改（在 VBA 或其他语言中）我们在上图中看到的地址簿解析顺序设置？

现在假设我在 GAL 中有 2 个类似的同音词（但在我的联系人中没有）：

• LASTNAME FirstName (Holding Company Name) <firstname.lastname@company.com>
• LASTNAME FirstName (Holding Company Name) <firstname.lastname1@company.com>

6) 如何在不遍历所有条目的情况下获得第二个 Exchange 用户（有很多条目可以做到这一点）？我尝试了几件事，要么得到第一个，要么得到错误的结果）

关于属性被截断的有趣帖子

7) 对于 EX 用户，我无法获得完整的专有名称，因为在我的情况下它太长了，被截断为 128 个字符：在 VBA（没有 CDO 或 RDO）中有没有办法获得完整的 DN？我已经尝试过PR_EMS_AB_OBJ_DIST_NAME了，但它给出的结果与该AddressEntry.Address属性相同

我正在尝试执行以下命令

但它总是将 node Provisioning State 设置为deploy failed.

我的节点如下所示。

我在 Glance 服务中拥有的图像列表如下所示

最后一个错误：

我的图片有什么问题？

导入 instack.json 文件时遇到以下错误。/var/log/containers/mistral/executor.log 中记录的错误。我在 CentOS 7.9 上使用 OpenStack RDO Train

2021-07-23 09:56:37.778 7 错误 misral.executors.default_executor
结果 = action.run(action_ctx) 2021-07-23 09:56:37.778 7 错误 misral.executors.default_executor 文件“/usr/lib/python2 .7/site-packages/mistral/actions/openstack/base.py”，第 130 行，在运行2021-07-23 09:56 : 37.778 7 错误 misral.executors.default_executor（self.class.name, self.client_method_name, str(e)) 2021-07-23 09:56:37.778 7 错误 misral.executors.default_executor ActionException：ZaqarAction.queue_post 失败：找不到合适的 TLS CA 证书包，路径无效：/etc/ pki/tls/certs/ca-bundle.crt 2021-07-23 09:56:37.778 7 错误 misral.executors.default_executor 2021-07-23 09:56:38.247 7 调试 misral.executors.executor_server [req-24ce4660- 9358-4020-90fe-447e14ceb623 6f7346e35aa44a75afccf063e84a1709 ba84abbbbe364e13b96a22bc8608bd4e - default default] Sending action result to engine [action_ex_id=a1b9eadb-c31b-472a-a3a6-139fb2d038db, action_cls=mistral.actions.openstack.actions.ZaqarAction] run_action /usr/lib/python2 .7/site-packages/mistral/executors/executor_server.py:114 2021-07-23 09:56:42.578 7 调试 mistra.executors。executor_server [req-6a326674-810c-40bb-a2b2-6216e80c33ef 6f7346e35aa44a75afccf063e84a1709 ba84abbbbe364e13b96a22bc8608bd4e - default default] Received RPC request 'run_action'[action_ex_id=b3f0570c-efa4-4f4c-9312-dce0e0d2ffe9, action_cls_str=mistral.actions.openstack.actions.ZaqarAction, action_cls_attrs={u'client_method_name'：u'queue_post'}，params={queue_name：tripleo，消息：{u'body'：{u'type'：u'tripleo.baremetal.v1.validate_nodes'，u'pay。 ..，超时=无] run_action /usr/lib/python2.7/site-packages/mistral/executors/executor_server.py:94 2021-07-23 09:56:42.595 7 DEBUG mistra.actions.openstack.actions [ req-6a326674-810c-40bb-a2b2-6216e80c33ef 6f7346e35aa44a75afccf063e84a1709 ba84abbbbe364e13b96a22bc8608bd4e - 默认默认值] Zaqar 操作安全上下文：<mistral_lib.actions。context.ActionContext 对象位于 0x7f206d4f4f90> _create_client /usr/lib/python2.7/site-packages/mistral/actions/openstack/actions.py:476 2021-07-23 09:56:42.608 7 警告mistral.actions.openstack。基础 [req-6a326674-810c-40bb-a2b2-6216e80c33ef 6f7346e35aa44a75afccf063e84a1709 ba84abbbbe364e13b96a22bc8608bd4e - 默认默认值] Traceback（最近一次调用）：文件“/usr/lib/python2.7/openstack.action py”，第 117 行，运行结果 = 方法（**self._kwargs_for_run）文件“/usr/lib/python2.7/site-packages/mistral/actions/openstack/actions.py”，第 499 行，包装返回方法（客户端，*args，**kwargs）文件“/usr/lib/python2.7/site-packages/mistral/actions/openstack/actions.py”，第 545 行，在 queue_post 返回 queue.post(messages) 文件“/usr/lib/python2.7/site-packages/zaqarclient/queues/v1/queues.py”，第 170 行，在帖子 self._name，消息中）文件“/usr/lib/python2.7/site-packages/zaqarclient/queues/v1/core .py”，第 242 行，在 message_post resp = transport.send(request) 文件“/usr/lib/python2.7/site-packages/zaqarclient/transport/http.py”，第 104 行，在 send verify=verify 中）文件“/usr/lib/python2.7/site-packages/zaqarclient/common/http.py”，第 28 行，在请求中返回 self.session.request(*args, **kwargs) 文件“/usr/lib/ python2.7/site-packages/requests/sessions.py”，第 533 行，在请求 resp = self.send(prep, **send_kwargs) 文件“/usr/lib/python2.7/site-packages/requests/sessions .py”，第 646 行，发送 r = adapter.send(request, **kwargs) 文件“/usr/lib/python2.7/site-packages/requests/adapters.py”，第 416 行，发送 self。cert_verify(conn, request.url, verify, cert) 文件“/usr/lib/python2.7/site-packages/requests/adapters.py”，第 228 行，在 cert_verify“无效路径：{}”.format(cert_loc )) IOError：找不到合适的 TLS CA 证书包，路径无效：/etc/pki/tls/certs/ca-bundle.crt：IOError：找不到合适的 TLS CA 证书包，路径无效：/etc/ pki/tls/certs/ca-bundle.crt 2021-07-23 09:56:42.609 7 WARNING mistral.executors.default_executor [req-6a326674-810c-40bb-a2b2-6216e80c33ef 6f7346e35aa44a75afccf063e84a1709 ba84abbbbe364e13b96a22bc8608bd4e - default default] The action raised an异常 [action_ex_id=b3f0570c-efa4-4f4c-9312-dce0e0d2ffe9, msg='ZaqarAction.queue_post 失败：找不到合适的 TLS CA 证书包，路径无效：/etc/pki/tls/certs/ca-bundle.crt' , action_cls='<类'mistral.actions.action_factory.ZaqarAction'>'，属性='{u'client_method_name'：u'queue_post'}'，参数='{u'queue_name'：u'tripleo'，u'messages'：{u 'body': {u'type': u'tripleo.baremetal.v1.validate_nodes', u'payload': {u'status': u'SUCCESS', u'root_execution_id': u'91f2c676-f31e-4bf3- 8c02-84eab02a879f'，u'message'：u''，u'plan_name'：无，u'execution_id'：u'7ecd0666-750d-4372-8329-bf81990e9405'，u'deployment_status'：无}}}}' ]：ActionException：ZaqarAction.queue_post 失败：找不到合适的 TLS CA 证书包，路径无效：/etc/pki/tls/certs/ca-bundle.crt 2021-07-23 09:56:42.609 7 错误 misral。执行人。default_executor Traceback（最近一次通话最后一次）：2021-07-23 09:56:42.609 7 ERROR misral.executors.default_executor
文件“/usr/lib/python2.7/site-packages/mistral/executors/default_executor.py”，第 133 行，在 _do_run_action 2021-07-23 09:56:42.609 7 错误 misral.executors.default_executor 结果 = action。运行（action_ctx）2021-07-23 09:56:42.609 7 错误 mistral.executors.default_executor
文件“/usr/lib/python2.7/site-packages/mistral/actions/openstack/base.py”，第 130 行，在运行2021-07-23 09:56 : 42.609 7 错误 misral.executors.default_executor (self.class.name, self.client_method_name, str(e)) 2021-07-23 09:56:42.609 7 错误 misral.executors.default_executor ActionException：ZaqarAction.queue_post 失败：找不到合适的 TLS CA 证书包，路径无效：/etc/ pki/tls/certs/ca-bundle.crt 2021-07-23 09:56:42.609 7 错误 misral.executors.default_executor 2021-07-23 09:56:42.750 7 调试 misral.executors.executor_server [req-6a326674- 810c-40bb-a2b2-6216e80c33ef 6f7346e35aa44a75afccf063e84a1709 ba84abbbbe364e13b96a22bc8608bd4e - default default] Sending action result to engine [action_ex_id=b3f0570c-efa4-4f4c-9312-dce0e0d2ffe9, action_cls=mistral.actions.openstack.actions.ZaqarAction] run_action /usr/lib/python2 .7/site-packages/mistral/executors/executor_server.py:114 2021-07-23 09:56:45.010 7 调试 mistrall.services。action_heartbeat_sender [req-4581e319-b80d-4aa9-b9a7-16c374dd28be - - - - -] 运行心跳报告器... send_action_heartbeats /usr/lib/python2.7/site-packages/mistral/services/action_heartbeat_sender.py:53 2021- 07-23 09:56:46.922 7 DEBUG mistral.executors.executor_server [req-6a326674-810c-40bb-a2b2-6216e80c33ef 6f7346e35aa44a75afccf063e84a1709 ba84abbbbe364e13b96a22bc8608bd4e - default default] Received RPC request 'run_action'[action_ex_id=99e06339-4d13-46f4-914d- 516d19e1ddd​​a，action_cls_str=mistral.actions.openstack.actions.ZaqarAction，action_cls_attrs={u'client_method_name'：u'queue_post'}，params={queue_name：三重，消息：{u'body'：{u'type'：u 'tripleo.baremetal.v1.validate_nodes', u'pay..., timeout=None] run_action /usr/lib/python2.7/site-packages/mistral/executors/executor_server。py:94 2021-07-23 09:56:46.928 7 DEBUG mistral.actions.openstack.actions [req-6a326674-810c-40bb-a2b2-6216e80c33ef 6f7346e35aa44a75afccf063e84a1709 ba84abbbbe364e13b96a22bc8608bd4e - default default] Zaqar action security context: <mistral_lib.actions. context.ActionContext 对象位于 0x7f206d405150> _create_client /usr/lib/python2.7/site-packages/mistral/actions/openstack/actions.py:476 2021-07-23 09:56:46.935 7 警告mistral.actions.openstack。基础 [req-6a326674-810c-40bb-a2b2-6216e80c33ef 6f7346e35aa44a75afccf063e84a1709 ba84abbbbe364e13b96a22bc8608bd4e - 默认默认值] Traceback（最近一次调用）：文件“/usr/lib/python2.7/openstack.action py”，第 117 行，运行结果 = 方法（**self._kwargs_for_run）文件“/usr/lib/python2.7/site-packages/mistral/actions/openstack/actions.py”，第 499 行，包装返回方法（客户端，*args，**kwargs）文件“/usr/lib/python2.7/site-packages/mistral/actions/openstack/actions.py”，第 545 行，在 queue_post 返回队列中.post(messages) 文件“/usr/lib/python2.7/site-packages/zaqarclient/queues/v1/queues.py”，第 170 行，在 post self._name，messages) 文件“/usr/lib/python2 .7/site-packages/zaqarclient/queues/v1/core.py”，第 242 行，在 message_post resp = transport.send(request) 文件“/usr/lib/python2.7/site-packages/zaqarclient/transport/ http.py”，第 104 行，在发送 verify=verify) 文件“/usr/lib/python2.7/site-packages/zaqarclient/common/http.py”，第 28 行，在请求中返回 self.session.request( *args, **kwargs) 文件“/usr/lib/python2.7/site-packages/requests/sessions.py”，第 533 行，在请求中 resp = self.send(prep,**send_kwargs) 文件“/usr/lib/python2.7/site-packages/requests/sessions.py”，第 646 行，在 send r = adapter.send(request, **kwargs) 文件“/usr/lib/ python2.7/site-packages/requests/adapters.py”，第 416 行，在发送 self.cert_verify(conn, request.url, verify, cert) 文件“/usr/lib/python2.7/site-packages/requests /adapters.py”，第 228 行，在 cert_verify “无效路径：{}”.format(cert_loc)) IOError：找不到合适的 TLS CA 证书包，无效路径：/etc/pki/tls/certs/ca- bundle.crt：IOError：找不到合适的 TLS CA 证书包，路径无效：/etc/pki/tls/certs/ca-bundle.crt 2021-07-23 09:56:46.936 7 警告 misral.executors。default_executor [req-6a326674-810c-40bb-a2b2-6216e80c33ef 6f7346e35aa44a75afccf063e84a1709 ba84abbbbe364e13b96a22bc8608bd4e - default default] The action raised an exception [action_ex_id=99e06339-4d13-46f4-914d-516d19e1ddd​​a, msg='ZaqarAction.queue_post failed: Could not find a suitable TLS CA 证书包，无效路径：/etc/pki/tls/certs/ca-bundle.crt'，action_cls='<class 'mistral.actions.action_factory.ZaqarAction'>'，attributes='{u'client_method_name'： u'queue_post'}', params='{u'queue_name': u'tripleo', u'messages': {u'body': {u'type': u'tripleo.baremetal.v1.validate_nodes', u '有效负载'：{u'status'：u'SUCCESS'，u'root_execution_id'：u'91f2c676-f31e-4bf3-8c02-84eab02a879f'，u'message'：u''，u'plan_name'：无，u'execution_id'：u'7ecd0666-750d-4372-8329-bf81990e9405'，u'deployment_status'：无}}}}']：ActionException：ZaqarAction.queue_post 失败：可能找不到合适的 TLS CA 证书包，路径无效：/etc/pki/tls/certs/ca-bundle.crt 2021-07-23 09:56:46.936 7 错误 misral.executors.default_executor Traceback（最近一次调用最后） ：2021-07-23 09:56:46.936 7 错误 misral.executors.default_executordefault_executor Traceback（最近一次通话最后一次）：2021-07-23 09:56:46.936 7 ERROR misral.executors.default_executordefault_executor Traceback（最近一次通话最后一次）：2021-07-23 09:56:46.936 7 ERROR misral.executors.default_executor
文件“/usr/lib/python2.7/site-packages/mistral/executors/default_executor.py”，第 133 行，在 _do_run_action 2021-07-23 09:56:46.936 7 错误 misral.executors.default_executor 结果 = action。运行（action_ctx）2021-07-23 09:56:46.936 7 错误 mistral.executors.default_executor
文件“/usr/lib/python2.7/site-packages/mistral/actions/openstack/base.py”，第 130 行，在运行2021-07-23 09:56 : 46.936 7 错误 misral.executors.default_executor (self.class.name, self.client_method_name, str(e)) 2021-07-23 09:56:46.936 7 错误 misral.executors.default_executor ActionException：ZaqarAction.queue_post 失败：找不到合适的 TLS CA 证书包，路径无效：/etc/ pki/tls/certs/ca-bundle.crt 2021-07-23 09:56:46.936 7 错误 misral.executors.default_executor 2021-07-23 09:56:47.158 7 调试 misral.executors.executor_server [req-6a326674- 810c-40bb-a2b2-6216e80c33ef 6f7346e35aa44a75afccf063e84a1709 ba84abbbbe364e13b96a22bc8608bd4e - default default] Sending action result to engine [action_ex_id=99e06339-4d13-46f4-914d-516d19e1ddd​​a, action_cls=mistral.actions.openstack.actions.ZaqarAction] run_action /usr/lib/python2 .7/site-packages/mistral/executors/executor_server.py:114 ^C [root@ucstaging ~]#

我们通过 Packstack 安装使用 Openstack-Train 设置，并将 Openvswitch 作为 neutron 的后端。

我们创建了一个外部网络 (10.5.0.0/22)，它是我们组织的内部网络。和通过路由器链接的专用网络 (10.3.0.0/22)。

我们的组织。网络与 Pfsense 防火墙连接，该防火墙已获准将网络 10.5.0.0/22 连接到 openstack 的 10.3.0.0/22，反之亦然。

在 openstack 的安全组中，我们添加了 egress 和 ingress 规则以允许两个网络之间的流量。

但是，我们无法从我们的组织 ping 或 SSH 构建在专用网络 (10.3.0.0/22) 上的任何 VM。网络（10.5.0.0/22）。

专用网络上的 VM 具有 Internet 连接，并且可以 ping google 和 ssh 进入我们的组织。位于 10.5.0.0/22 ip 范围内的机器。

SSH 进入专用网络虚拟机的唯一方法似乎是通过浮动 IP。

有没有办法不使用浮动 IP 直接 SSH 进入私有网络虚拟机？或者这是 openstack 设计的一部分？

谢谢

我已经在 Virtual Box 上部署了 RDO Openstack Xena。安装没有错误。创建外部网络另一个名为蓝色的网络并将其连接到路由器。我将 8.8.8.8 定义为 DNS。一切看起来都很好，但是当我创建 Cirros 实例时，该实例无法在 Internet 之外 ping。已定义浮动 IP。第二个 Cirros 实例也有同样的问题。

任何帮助深表感谢。

抱歉，如果这篇文章的格式不正确。这是我在这里的第一个问题。如果是这样，请让我知道如何解决。

Openstack 设置与 RDO packstack all-in-one。在 Centos-8-Stream 上运行。

我已将我的公钥导入 Horizo​​n 并在创建实例时选择它。创建实例后，我可以正常 ping 它，但无法通过 SSH 连接到它。我要么得到：Unable to negotiate with .... port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1要么通常：

ssh: connect to host .... port 22: Connection refused

运行时，openstack console log show testVM我注意到我得到ci-info: no authorized SSH keys fingerprints found for user ubuntu.了并且我的公钥没有像应有的那样列出。

我也看到了cloud-init[332]: 2022-03-02 21:58:25,772 - util.py[WARNING]: No active metadata service found。

我认为元数据代理一定与它有关，所以我检查了 neutron-ovn-metadata 服务。它似乎正常运行。

我还检查了 nova-api 日志并找到了下面的日志。我不确定这是否与我的问题有关。

我对 neutron_ovn_metadata 不是很熟悉，我已经做了尽可能多的调查，但没有运气。如果有人遇到过类似的问题并能指出我正确的方向，我将不胜感激。

我可以发布您需要的任何其他日志或信息。我发布了我认为相关的内容，但我可能遗漏了一些内容。