ProcessingFlow中怎样调用lua脚本

baode_liangbing · 2026 年4 月 9 日 13:32

问题描述

通过POST /redfish/v1/Managers/:managerid/LogServices/Actions/Oem/{{OemIdentifier}}/CollectNPULog调用logservices.lua脚本里面的函数collect_npu_log，当前我的做法如下：

    {

        "Uri": "/redfish/v1/Managers/:managerid/LogServices/Actions/Oem/{{OemIdentifier}}/CollectNPULog",

        "Interfaces": \[

            {

                "Type": "POST",

                "ResourceExist": {

                    "${Statements/IsValidManagersId()}": true,

                    "${Statements/CollectNPULog()}": true

                },

                "ReqBody": {

                    "Type": "object",

                    "Required": true,

                    "Properties": {}

                },

                "RspBody": {},

                "Statements": {

                    "IsValidManagersId": {

                        "Steps": \[

                            {

                                "Type": "Plugin",

                                "Formula": "utils.is_valid_managers_id(Uri.managerid)"

                            }

                        \]

                    },

                    "CollectNPULog": {

                        "Steps": \[

                            {

                                "Type": "Plugin",

                                "Formula": "orchestrator.logservices.collect_npu_log()"

                            }

                        \]

                    }

                }

            }

        \]

    }

即通过ResourceExist触发Statements的CollectNPULog来调用脚本，这样做可以成功但是否合理，有其他直接调用脚本的方法吗？

ProcessingFlow支持的类型Property/Method/List/Task/Paging没有可以调用脚本的。

环境信息

基于openubmc 2512_lts

~ ~ $ ipmcget -d version
------------------- openUBMC INFO -------------------
IPMC CPU: Hi1711
IPMI Version: 2.0
Active openUBMC Version: 1.17.10
Active openUBMC Build: 01
Active openUBMC Built: 14:33:07 Mar 27 2026
Backup openUBMC Version: 1.17.10
Available openUBMC Version: 1.00.16
Available openUBMC Build: 01
Active Uboot Version: 21.3.10.1 (09:53:00 Dec 30 2025)
Backup Uboot Version: 21.3.10.1 (09:53:00 Dec 30 2025)
Active Secure Bootloader Version: 21.3.10.1 (09:51:37 Dec 30 2025)
Backup Secure Bootloader Version: 21.3.10.1 (09:51:37 Dec 30 2025)
Active Secure Firmware Version: 21.3.10.1 (09:51:38 Dec 30 2025)
Backup Secure Firmware Version: 21.3.10.1 (09:51:38 Dec 30 2025)
Active BMCSDK Version: 5.12.00.01
----------------- Product INFO -----------------
Product ID: 0x0000
Product Name: Atlas 800I A3
Product Unique ID: 0x000000010302BF02
Active BIOS Version: (U75)21.23
Backup BIOS Version: 21.23

重现步骤

见问题描述

期望结果

url能直接调用lua脚本

实际结果

无

尝试过的解决方案

无

分析结论

无

ubmc_assistant · 2026 年4 月 9 日 13:35

答案内容由AI生成，仅供参考：

结论

当前通过 ResourceExist 调用 Statements 执行 Lua 脚本的方法虽然功能可行，但不符合设计规范，属于误用。

推荐解决方案：

将 collect_npu_log() 的调用移至 ProcessingFlow，使用 Plugin 类型进行调用：
"ProcessingFlow": [
  {
    "Type": "Plugin",
    "Formula": "orchestrator.logservices.collect_npu_log()"
  }
]

这种方式符合 openUBMC 的接口映射设计规范，语义清晰、可维护性强，是标准的 Redfish 接口定制化开发模式。

点击此处查看详细分析解答

ProcessingFlow 中调用 Lua 脚本的方式分析

根据您提供的上下文信息，以下是对在 ProcessingFlow 中如何调用 Lua 脚本的详细分析与建议。

问题核心

您希望通过 POST 请求：

/redfish/v1/Managers/:managerid/LogServices/Actions/Oem/{{OemIdentifier}}/CollectNPULog

调用自定义的 logservices.lua 脚本中定义的 collect_npu_log() 函数。

当前实现方式是：通过 ResourceExist 触发 Statements 中的函数调用，虽然能够成功，但疑虑其是否为合理设计。

当前做法是否合理？

当前方法分析（使用 `Statements` + `Plugin`）

"ResourceExist": {
  "${Statements/IsValidManagersId()}": true,
  "${Statements/CollectNPULog()}": true
}

机制说明：
- ResourceExist 用于校验资源是否存在，通常用于 URI 参数合法性检查。
- 通过 ${Statements/...} 表达式调用 Statements 块中定义的方法。
- Statements/CollectNPULog 使用 "Type": "Plugin" 和 "Formula": "orchestrator.logservices.collect_npu_log()"，表示调用名为 collect_npu_log 的 Lua 函数。
当前做法的合理性评估：
- 能工作：此方式符合 openUBMC 的映射配置机制。
- 不推荐：将业务逻辑（日志收集）嵌入 ResourceExist 是一种 滥用设计意图的行为。
  - ResourceExist 的语义应为“资源存在性检查”，不应承载“执行操作”的副作用。
  - 可能导致行为不可预测，尤其在 GET/PUT 等其他请求中误触发。
  - 不符合接口配置的清晰分层原则。

正确调用 Lua 脚本的方法

虽然 ProcessingFlow 支持的类型（Property/Method/List/Task/Paging）本身不直接支持“执行脚本”，但可通过以下标准方式实现 Lua 逻辑调用：

推荐方案一：使用 `ProcessingFlow` + `Plugin` 执行 Lua 函数（标准做法）

关键点：业务逻辑应在 ProcessingFlow 中执行，而非 ResourceExist。

示例配置：

{
  "Uri": "/redfish/v1/Managers/:managerid/LogServices/Actions/Oem/{{OemIdentifier}}/CollectNPULog",
  "Interfaces": [
    {
      "Type": "POST",
      "ResourceExist": {
        "${Statements/IsValidManagersId()}": true
      },
      "ReqBody": { "Type": "object", "Required": true, "Properties": {} },
      "RspBody": {
        "Message": "NPU Log collection initiated.",
        "Status": "${ProcessingFlow[1]/Destination/State}"
      },
      "Statements": {
        "IsValidManagersId": {
          "Steps": [
            {
              "Type": "Plugin",
              "Formula": "utils.is_valid_managers_id(Uri.managerid)"
            }
          ]
        }
      },
      "ProcessingFlow": [
        {
          "Type": "Plugin",
          "Formula": "orchestrator.logservices.collect_npu_log()"
        }
      ]
    }
  ]
}

优势：

符合语义规范：ProcessingFlow 用于执行操作流程，ResourceExist 用于资源校验。
易于调试和维护。
支持异步任务、返回状态等扩展能力。

推荐方案二：使用 `Script` 类型直接写入或引用 Lua 脚本（轻量逻辑）

如果逻辑简单且无需复用，可使用 Script 类型：

"ProcessingFlow": [
  {
    "Type": "Script",
    "Formula": "return orchestrator.logservices.collect_npu_log()"
  }
]

或外置脚本文件：

"ProcessingFlow": [
  {
    "Type": "Script",
    "Formula": "logservices/collect_npu_log.lua"
  }
]

要求：脚本文件位于 plugins/script/logservices/collect_npu_log.lua

注意事项：

Script 不可复用，适合一次性逻辑。
长脚本建议外置为 .lua 文件。
ProcessingFlow 中的 Script 执行时机明确，在请求处理主流程中。

关键概念解析

概念	说明	适用场景
Plugin	调用 Lua 函数，`Formula` 格式为 `module.function()`	可复用、模块化业务逻辑
Script	内联或外置 Lua 脚本，执行任意逻辑	轻量、一次性逻辑
Statements	命名逻辑块，可在 `ResourceExist` 或 `ProcessingFlow` 中引用	提前定义检查或处理逻辑
ResourceExist	仅用于验证 URI 中槽位是否存在，不应有副作用	资源存在性判断
ProcessingFlow	核心执行流程，支持 Plugin/Script/Property/Method/List	主业务逻辑执行路径

正确做法：将“执行操作”放入 ProcessingFlow，将“校验条件”放入 ResourceExist。

实现前提条件（确保能调用成功）

1. Lua 脚本路径与命名空间正确

假设脚本位置为：

interface_config/redfish/plugins/orchestrator/logservices.lua

文件内容结构应如下：

local m = {}

function m.collect_npu_log()
    local log = require 'mc.logging'
    log.info("Starting NPU log collection...")
    
    -- 实际日志收集逻辑
    -- ...

    return { State = "Completed", Progress = 100 }
end

return m

2. 插件加载路径规范

openUBMC 默认插件目录：/opt/bmc/apps/redfish/interface_config/plugins/
映射关系由 Formula 决定：
"orchestrator.logservices.collect_npu_log" → plugins/orchestrator/logservices.lua

3. 日志调试支持

可添加日志输出辅助调试：

local log = require 'mc.logging'
log.info("collect_npu_log called with input: %s", cjson.encode(Input))

相关日志可在 /var/log/app.log 查看。

不推荐的做法总结

方法	问题
在 `ResourceExist` 中调用业务函数	语义错误，可能引发副作用
将长脚本内联在 JSON 中	可读性差，维护困难
使用不存在的 `Method` 类型调用脚本	`Method` 是 D-Bus 接口调用，非 Lua 脚本入口

最佳实践建议

项目	推荐做法
调用 Lua 脚本	使用 `ProcessingFlow` + `Plugin`
脚本组织	按模块拆分 `plugins/orchestrator/*.lua`
函数命名	使用清晰的命名空间如 `orchestrator.logservices.collect_npu_log`
错误处理	使用 `pcall` 包裹关键调用，避免崩溃
调试支持	添加 `mc.logging` 日志输出
配置分离	复杂脚本外置为 `.lua` 文件

结论