关于Nova-Conductor与Nova-Compute角色差异及文档描述与代码实现矛盾的技术问询

嘿，这个问题真的戳中了Nova架构里很容易混淆的点！我当初刚啃Nova源码的时候也对着这段代码愣了半天，咱们慢慢理清楚：

首先先把你提到的官方文档描述贴出来，方便对照：

OpenStack社区描述：
nova-conductor模块：
中介nova-compute服务与数据库之间的交互。它消除了nova-compute服务对云数据库的直接访问。nova-conductor模块支持水平扩展。但是，不要将其部署在运行nova-compute服务的节点上。

RedHat描述：
nova-conductor服务使OpenStack能够在计算节点不访问数据库的情况下运行。从概念上讲，它在nova-compute之上实现了一个新层。不应将其部署在计算节点上，否则消除nova-compute对数据库访问的安全优势将被抵消。

然后你在nova/compute/manager.py里看到的这些代码片段：

def _poll_rescued_instances(self, context):
    if CONF.rescue_timeout > 0:
        filters = {'vm_state': vm_states.RESCUED,
                   'host': self.host}
        rescued_instances = objects.InstanceList.get_by_filters(
            context, filters, expected_attrs=["system_metadata"],
            use_slave=True)

def _allocate_network(self, context, instance, requested_networks,
                      security_groups, resource_provider_mapping,
                      network_arqs):
    """Start network allocation asynchronously.  Return an instance
    of NetworkInfoAsyncWrapper that can be used to retrieve the
    allocated networks when the operation has finished.
    """
    # NOTE(comstud): Since we're allocating networks asynchronously,
    # this task state has little meaning, as we won't be in this
    # state for very long.
    instance.vm_state = vm_states.BUILDING
    instance.task_state = task_states.NETWORKING
    instance.save(expected_task_state=[None])

核心澄清：文档描述和代码实现并不矛盾！ #

你看到的这些代码并不是直接的数据库操作，而是调用了Nova的Objects框架API——这是Nova用来抽象数据访问的核心层，它的作用就是把业务代码和底层数据访问逻辑解耦：

1. 架构设计的目标是「compute节点不直接连接数据库」：文档里的描述是Nova架构的最佳实践和设计意图，也就是compute节点不应该持有数据库的连接权限，所有需要操作数据库的请求都应该通过conductor中转。
2. Objects层自动路由请求：当部署符合规范（compute节点没有数据库权限）时，objects.InstanceList.get_by_filters、instance.save这些方法会自动通过RPC调用nova-conductor，由conductor来执行实际的数据库读写操作；只有当部署时故意给了compute节点数据库权限（这是不推荐的非安全配置），这些调用才会直接访问数据库。
3. 本地实例的特殊场景：比如_poll_rescued_instances里用'host': self.host过滤本节点的实例，这种场景下Objects层可能会允许从本地只读副本读取（如果配置了），但写入操作依然会强制走conductor，保证数据一致性和安全。

简单来说：文档说的是「架构设计上compute不应该直接碰数据库」，而代码里的调用是通过抽象层来实现这个设计——业务代码只需要调用Objects API，底层自动决定是走conductor还是（不推荐的）直接访问，这样既保证了架构的安全性，又让业务代码保持简洁。

所以结论是：OpenStack和RedHat的文档描述是完全正确的，代码实现是对这个设计的落地，二者不存在矛盾，只是需要理解Nova Objects这个中间层的作用。

备注：内容来源于stack exchange，提问作者Huy vō lè