openubmc 对外扩展接口-redfish

redfish 接口

openUBMC的SDK已经提供了完备的Redfish协议管理能力，并提供了强大的映射配置器，简化北向接口的适配工作量。
具体关于接口映射配置的介绍，请参考《接口映射配置》

映射配置增加 ​

redfish 是一个独立的组件，使用时先获取当前Redfish相关接口的映射配置仓

cd /home/workspace
git clone https://gitcode.com/openUBMC/rackmount.git

打开rackmount文件夹后，我们可以发现，在interface_config/redfish/mapping_config下，每一个文件对应着一个Redfish的路径。

我们希望扩展一个Redfish接口，路径为：/redfish/v1/OpenUBMC

首先在interface_config/redfish/mapping_config下创建文件：OpenUBMC.json，并粘贴以下代码

{
    "Resources": [
        {
            "Uri": "/redfish/v1/OpenUBMC",
            "Interfaces": [
                {
                    "Type": "GET",
                    "RspBody": {
                        "@odata.id": "/redfish/v1/OpenUBMC",
                        "@odata.type": "#OpenUBMC.OpenUBMC",
                        "Id": "OpenUBMC",
                        "Name": "OpenUBMC",
                        "WelcomeMessage": "${ProcessingFlow[1]/Destination/WelcomeMessage}"
                    },
                    "ProcessingFlow": [
                        {
                            "Type": "Property",
                            "Path": "/bmc/demo/MyMDSModel/1",
                            "Interface": "bmc.demo.OpenUBMC.Community",
                            "Destination": {
                                "WelcomeMessage": "WelcomeMessage"
                            }
                        }
                    ]
                }
            ]
        }
    ]
}

这里我们通过接口映射配置，不仅将Redfish的uri资源进行了具体的定义，并将Redfish的uri资源与openUBMC资源协作接口关联了起来，开发者无需再编写Redfish的接口代码逻辑。

组件构建 ​

由于修改了rackmount仓库，因此我们需要对rackmount仓库进行重新构建。

为了和之前版本进行区分，我们需要将rackmount/mds/service.json中的version字段进行更新

bingo build --stage=stable

构建错误

如果直接进行构建，会发现出现以下错误

rackmount/1.110.151@openubmc/stable: ERROR: 
Package 'b351ec081a9b090aa4bbeeaf6d9f94e2f84ec30b' build failed
rackmount/1.110.151@openubmc/stable: WARN: Build folder /root/.conan2/p/b/rackmcdea33fc3084c/b/.build/Debug
Formatted output saved to '/tmp/tmpcrg23dju.graph.json'
ERROR: rackmount/1.110.151@openubmc/stable: Error in build() method, line 66
        MapperCheck.check()
        JSONDecodeError: Expecting value: line 28 column 29 (char 1158)
ERROR: 执行命令 conan create --name rackmount --version 1.110.151 . -pr:h profile.luajit.ini -pr:b profile.dt.ini -s:h build_type=Debug --user openubmc --channel stable -o */*:enable_luajit=True --build=rackmount/* --build=missing -f json --out-file=/tmp/tmpcrg23dju.graph.json -tf= 错误, 日志: /root/.bmcgo_log/bingo.log
ERROR: Command '['conan', 'create', '--name', 'rackmount', '--version', '1.110.151', '.', '-pr:h', 'profile.luajit.ini', '-pr:b', 'profile.dt.ini', '-s:h', 'build_type=Debug', '--user', 'openubmc', '--channel', 'stable', '-o', '*/*:enable_luajit=True', '--build=rackmount/*', '--build=missing', '-f', 'json', '--out-file=/tmp/tmpcrg23dju.graph.json', '-tf=']' returned non-zero exit status 1.
ERROR: 请查看日志信息

原因

Redfish 接口必须在 PrivilegeMap 里声明权限。构建时 MapperCheck.check_privilege_map() 一旦 PrivilegeMap 检查返回失败，就会写死打印 NULL。

检查逻辑是：每个 Redfish GET 资源都必须在 PrivilegeMap 里声明权限。发现 OpenUBMC 没有配置后，check_get_uri() 直接 return 停掉，后面那些本来有 GET 的资源（Account、Chassis、Systems 等）都没登记进父资源表。接着检查 POST Action 时找不到父资源，就刷出一长串「无法获取根资源」。

我们在 interface_config/redfish/mapping_config/OpenUBMC.json 新增了：

URI：/redfish/v1/OpenUBMC
@odata.type：#OpenUBMC.OpenUBMC → 检查器用的类型名是 OpenUBMC
PrivilegeMap.json 的 Mappings 里没有 Entity: OpenUBMC。

但是在 interface_config/redfish/mapping_config/AccountService/PrivilegeMap/PrivilegeMap.json 的 Mappings 里没有 Entity: OpenUBMC。

解决方案

在 interface_config/redfish/mapping_config/AccountService/PrivilegeMap/PrivilegeMap.json 的 Mappings 里补一项，和只读 GET 资源一样即可，例如：

{
    "Entity": "OpenUBMC",
    "OperationMap": {
        "GET": [
            {
                "Privilege": ["Login"]
            }
        ]
    }
}

这样就可以成功构建了。

Created package revision 73509a8fdc12d10252fc7dafbf7eee53
Package 'b351ec081a9b090aa4bbeeaf6d9f94e2f84ec30b' created
Full package reference: rackmount/1.110.151@openubmc/stable#b79e0304ae4852ab37a0bd8a6e093ba8:b351ec081a9b090aa4bbeeaf6d9f94e2f84ec30b#73509a8fdc12d10252fc7dafbf7eee53
Package folder /root/.conan2/p/b/rackmaa0b5f316b3f2/p
Formatted output saved to '/tmp/tmpfofshiv3.graph.json'
========== sr 文件检查开始 ==========
没有找到['sr']后缀的文件！
========== sr 文件检查结束 ==========
构建成功

不要去注释 check_privilege_map()，那只是个人出包的临时绕过，不是修法。

整包构建 ​

组件添加

在 manifest/build/product/BMC/openUBMC/manifest.yml 文件 dependencies: 下面添加我们刚构建的组件

dependencies:
  - conan: "rackmount/1.110.151@openubmc/stable"

整包构建

cd /home/workspace/manifest
bingo build

构建完成后，便可在manifest/output中查看构建包。

整包测试 ​

无硬件环境验证组件集成

如果您当前没有真实的BMC硬件，可以通过检查整包构建产物的方式，验证新组件已被正确集成到产品包中。

整包构建过程中，会先在temp构建工作区生成集成后的rootfs目录（tmp_root），它就是hpm包内rootfs镜像的直接来源，其中的文件会原样打包进升级包。因此只需检查该目录：

# 查看新增加的OpenUBMC.json
ls temp/build_openUBMC_debug_dev/tmp_root/opt/bmc/apps/redfish/interface_config/mapping_config/OpenUBMC.json

不会出现成 opt/bmc/apps/rackmount 这种独立目录。

my_app 是 Kepler 应用，打包路径就是 opt/bmc/apps/my_app，所以你能在 apps/ 下看到同名文件夹。

rackmount 是北向映射器，package() 会把内容拆进现有接口组件里：

opt/bmc/apps/redfish/
opt/bmc/apps/web_backend/
opt/bmc/apps/cli/
opt/bmc/apps/snmp/

文档元数据在：

usr/share/doc/openubmc/rackmount/