This is an automated email from the ASF dual-hosted git repository.
JiaLiangC pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/ambari-website.git
The following commit(s) were added to refs/heads/main by this push:
new bb55c64 AMBARI-26663: Document the mpack store and new console
workflows (#45)
bb55c64 is described below
commit bb55c64f2aee994b8ffae7279bedd82bb9e8e4ed
Author: jialiang <[email protected]>
AuthorDate: Tue Sep 29 16:11:45 2026 +0800
AMBARI-26663: Document the mpack store and new console workflows (#45)
* AMBARI-26663: Add compact mpack and console documentation screenshots
* AMBARI-26663: Document the runtime mpack store and console workflows in
both languages
---
README.md | 5 +-
.../version-3.1.0.json | 4 +
.../ambari-design/enhanced-configs/index.md | 4 +
.../stack-and-services/management-packs.md | 6 +
.../version-3.1.0/frontend/react-ui.md | 6 +
.../frontend/workspace-and-appearance.md | 84 ++++++++++
.../version-3.1.0/introduction.md | 1 +
.../management-packs/authoring-and-bundling.md | 171 +++++++++++++++++++++
.../management-packs/content-configuration.md | 111 +++++++++++++
.../management-packs/operations-and-recovery.md | 128 +++++++++++++++
.../version-3.1.0/management-packs/overview.md | 86 +++++++++++
.../management-packs/service-catalog.md | 89 +++++++++++
.../version-3.1.0/management-packs/store-guide.md | 90 +++++++++++
.../monitoring/queries-and-dashboards.md | 45 ++++++
.../version-3.1.0/release-baseline.md | 19 +++
.../version-3.1.0/release-notes.md | 8 +
static/img/3.1.0/mpack-store/catalog-dark.jpg | Bin 0 -> 48536 bytes
.../3.1.0/mpack-store/configuration-files-dark.jpg | Bin 0 -> 36688 bytes
static/img/3.1.0/mpack-store/legend-controls.jpg | Bin 0 -> 16158 bytes
tests/e2e/i18n.spec.ts | 2 +-
tests/i18n.test.mjs | 6 +-
.../ambari-design/enhanced-configs/index.md | 4 +
.../stack-and-services/management-packs.md | 6 +
versioned_docs/version-3.1.0/frontend/react-ui.md | 6 +
.../frontend/workspace-and-appearance.md | 84 ++++++++++
versioned_docs/version-3.1.0/introduction.md | 1 +
.../management-packs/authoring-and-bundling.md | 171 +++++++++++++++++++++
.../management-packs/content-configuration.md | 111 +++++++++++++
.../management-packs/operations-and-recovery.md | 128 +++++++++++++++
.../version-3.1.0/management-packs/overview.md | 86 +++++++++++
.../management-packs/service-catalog.md | 89 +++++++++++
.../version-3.1.0/management-packs/store-guide.md | 90 +++++++++++
.../monitoring/queries-and-dashboards.md | 45 ++++++
versioned_docs/version-3.1.0/release-baseline.md | 19 +++
versioned_docs/version-3.1.0/release-notes.md | 8 +
versioned_sidebars/version-3.1.0-sidebars.json | 14 ++
36 files changed, 1724 insertions(+), 3 deletions(-)
diff --git a/README.md b/README.md
index e51ac6a..d47f7e1 100644
--- a/README.md
+++ b/README.md
@@ -70,10 +70,13 @@ Translation preserves the source's technical content,
including historical
instructions and illustrative code; it is not a technical modernization of
those guides.
-The separate 3.1.0 preview contains 71 paired English/Chinese guides based on
+The separate 3.1.0 preview contains 84 paired English/Chinese guides based on
the 3.1 implementation. It retains current installation, development,
Blueprint, Kerberos, Stack/service, View, configuration, and alert topics
alongside monitoring, runtime/package changes, React, and upgrade planning.
+It also includes the explicitly identified AMBARI-26663 runtime mpack store
+follow-up: import/deployment, service prerequisites, complete configuration
+content, package authoring, recovery, console appearance, and navigation.
The old unversioned `docs/` tree is not published as `Next`; obsolete AMS,
Ganglia, SCOM, and Ember widget tutorials are not carried into 3.1.
Old `/docs/next/` links redirect to the corresponding 3.1 guides, retaining
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0.json
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0.json
index 15c2cb6..98d0273 100644
--- a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0.json
+++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0.json
@@ -1,4 +1,8 @@
{
+ "sidebar.ambariSidebar.category.Management Pack Store": {
+ "message": "管理包商店",
+ "description": "The label for category 'Management Pack Store' in sidebar
'ambariSidebar'"
+ },
"version.label": {
"message": "3.1.0（预览）",
"description": "The label for the upcoming 3.1.0 documentation"
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/ambari-design/enhanced-configs/index.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/ambari-design/enhanced-configs/index.md
index 9e00830..915706e 100644
---
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/ambari-design/enhanced-configs/index.md
+++
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/ambari-design/enhanced-configs/index.md
@@ -41,6 +41,10 @@ Ambari 将 Stack 默认值、集群期望配置、匹配的配置组覆盖以及
依赖更新仅限于已更改属性。recommendations
请求接收更改配置列表，并仅返回受影响的依赖项。无效元数据、不支持的小部件定义或超出声明约束的值必须在保存前修正。
+## 完整原生配置文档 {#complete-native-documents}
+
+运行时 mpack 后续版本使用 `content` 属性管理十项参考服务的完整原生文件，包括 PostgreSQL 和
Nginx。配置文件与基本设置的职责不同：应用文档与受管理的身份、路径、凭据和监听输入共同存在。迁移、配置组继承、校验与恢复边界见[编辑完整配置文件](../../management-packs/content-configuration.md)。
+
## 保存和重新加载 {#save-and-reload}
Ambari 通过常规配置 API 保存最终配置。主题或 Stack 定义更改后必须重启 Ambari Server 才能重新加载元数据。3.1
保留主题；已移除的旧监控小部件模型与这些配置表单控件无关。
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/ambari-design/stack-and-services/management-packs.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/ambari-design/stack-and-services/management-packs.md
index d847af7..d407dda 100644
---
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/ambari-design/stack-and-services/management-packs.md
+++
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/ambari-design/stack-and-services/management-packs.md
@@ -21,6 +21,12 @@ limitations under the License.
# 管理包 {#management-packs}
+:::info 运行时商店与旧版安装
+整体导入商店、选择服务、管理完整配置以及恢复持久化操作，请阅读[运行时 mpack
商店指南](../../management-packs/overview.md)。该指南描述 AMBARI-26663 开发后续实现。
+
+下方命令行流程介绍固定源码修订中的旧式安装阶段机制，不能把它的暂存、重启行为推广到所有运行时商店操作。应使用所选机制要求的清单和工具，同样叫作
`mpack.json` 不代表归档相互兼容。
+:::
+
Ambari 管理包是包含堆栈、服务、扩展或视图制品以及 `mpack.json` 元数据的归档。Server 的 `setupMpacks.py`
会展开归档、读取元数据、验证前置条件、暂存管理包，并创建堆栈加载器使用的资源。
## 元数据 {#metadata}
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/frontend/react-ui.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/frontend/react-ui.md
index 8b8c50c..d2e7828 100644
---
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/frontend/react-ui.md
+++
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/frontend/react-ui.md
@@ -87,6 +87,12 @@ React 在 `/main/monitoring` 提供原生 Prometheus 兼容监控区域，包括
旧版独立 Heatmaps 页面会重定向到 `/main/dashboard/metrics`。这是明确的替换边界：React 不提供 AMS 或
Ganglia 兼容路径，因此旧 Heatmaps 页面及 AMS/Ganglia 行为不属于尚待补齐的 React 功能。
+## 工作区导航与外观 {#workspace-navigation-and-appearance}
+
+AMBARI-26663
开发后续版本增加了按服务聚合的管理包选择、醒目的全局导航、返回原集群页面、持久化的浅色/暗色/跟随系统外观、紧凑主机告警链接，以及更清晰的监控交互。这些能力需要对应实现，不能仅凭较早的
React 基线认定已经提供。
+
+可见入口和状态边界见[工作区导航与外观](./workspace-and-appearance.md)，导入并部署所选服务的步骤见[商店使用流程](../management-packs/store-guide.md)。
+
## 构建和部署 {#build-and-deployment}
Maven 的 `ambari-web` 模块使用配置的 Node/npm 工具链，从 `ambari-web/latest` 构建主要 React
应用并写入 `latest/dist`；Maven 会将该输出复制到服务器 Web UI 构件中。独立的 `ambari-admin` 模块从
`src/main/resources/ui/ambari-admin` 构建 Admin React 应用，并将输出打包到 `classes/latest`。
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/frontend/workspace-and-appearance.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/frontend/workspace-and-appearance.md
new file mode 100644
index 0000000..813164f
--- /dev/null
+++
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/frontend/workspace-and-appearance.md
@@ -0,0 +1,84 @@
+---
+title: 工作区导航与外观
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# 工作区导航与外观 {#workspace-navigation-and-appearance}
+
+本指南介绍[运行时 mpack 开发快照](../management-packs/overview.md)中的控制台改进，范围为主 React
控制台及桌面操作。嵌入应用和独立部署的界面可能具有自己的导航与外观。
+
+## 全局目录与集群工作区 {#global-and-cluster}
+
+全局导航提供**集群**、**服务**和仅管理员可见的**管理包**入口。集群和管理包也位于集群侧栏上方，在仪表盘、监控、服务、主机、告警等集群功能之前。
+
+全局目录用于选择环境和管理定义；集群工作区用于服务配置与日常操作。应用顶部会明确显示当前集群。
+
+
+
+菜单是否显示取决于账号权限。管理员菜单不可见，并不表示安装缺失，手工输入路由也不会增加权限。
+
+## 返回离开前的页面 {#return-to-workspace}
+
+从集群进入全局目录时，控制台会在当前账号的浏览器会话中记录准确的集群路径及查询参数。
+
+点击**返回工作区**即可打开该页面。例如，从某服务的 Configs 离开，依次访问集群目录和管理包，即使刷新了全局页面，仍可返回原来的服务路径及 URL
参数。
+
+记录按账号和浏览器会话隔离。新会话没有访问过集群页面时，可能不显示返回入口。此功能恢复导航，不恢复未保存的表单内容；仍应遵守未保存提示、当前权限以及集群、服务是否存在等检查。
+
+## 选择浅色、暗色或跟随系统 {#appearance}
+
+点击顶栏语言控件旁边的太阳、月亮或显示器图标，打开**外观**菜单。登录页也提供该入口。
+
+| 选项 | 行为 |
+| --- | --- |
+| 浅色 | 始终使用浅色控制台，不受系统外观影响 |
+| 暗色 | 始终使用暗色控制台，不受系统外观影响 |
+| 跟随系统 | 跟随操作系统的浅色、暗色偏好 |
+
+显式选择属于浏览器偏好，刷新后保留，并与同源的其他标签页同步。切换不会修改集群配置或重启服务。浏览器存储不可用时，当前标签页仍可切换外观。
+
+暗色设计采用石墨灰分层、浅色文字和明确的选中态。IBM Plex Sans 由应用本地提供；中文使用可用的 CJK 无衬线字体，配置文档与代码保持等宽显示。
+
+外观覆盖主导航、表格、配置控件、常用弹窗、图表轴与图例、状态标签和分页。判断状态时，应同时看严重程度文字和数量，不能只看颜色。
+
+## 服务配置与版本控件 {#configuration-controls}
+
+服务的 Summary 与 Configs 仍是不同页签。修改配置前先选择配置组和版本，版本菜单和配置组弹出菜单会使用当前外观。
+
+参考商店的[完整配置文件流程](../management-packs/content-configuration.md)展示原生完整文档，基本设置则保留管理输入。保存新版本仍需要相应配置权限，并按要求执行后续重启或
reload。
+
+## 主机告警数量 {#host-alert-counts}
+
+主机名旁的紧凑徽标显示严重与警告告警的总数。存在严重告警时优先使用严重状态样式，只有警告时使用对应样式；总数为零时不显示徽标。
+
+悬停或聚焦可以了解主机与严重程度细分。激活徽标会进入该主机的 Alerts 页面，点击主机名称则进入
Summary。徽标使用正常的可访问链接，也支持键盘操作。
+
+主机健康、维护状态、待重启项和告警数量是不同指标，因此健康图标和告警徽标可以同时出现。
+
+## 监控操作 {#monitoring-interactions}
+
+刷新偏好、秒级时间范围、查询取消、空结果与错误提示、采集目标详情和序列显示操作，见[查询与仪表盘](../monitoring/queries-and-dashboards.md#workspace-interactions)。
+
+查询端点、数据采集目标和展示的图表属于不同层次。隐藏曲线不会停止采集；数据源已启用只是配置状态，不证明连接测试或所有采集都成功。
+
+## 处理旧浏览器页面 {#browser-recovery}
+
+开发部署替换 Web 文件后，应刷新页面加载新的应用。如果旧标签页仍显示之前的菜单，先核对实际加载的构建，再判断功能是否缺失。
+
+管理包提交响应丢失时，需要按操作身份恢复，不能通过反复刷新、重复提交解决。该流程见[管理包恢复](../management-packs/operations-and-recovery.md)。
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/introduction.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/introduction.md
index 0ebbf92..d4fb903 100644
--- a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/introduction.md
+++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/introduction.md
@@ -24,6 +24,7 @@ limitations under the License.
| 领域 | 3.1.0 变更 | 指南 |
| --- | --- | --- |
+| 管理包商店预览 | 在匹配的开发构建中整体导入商店、选择服务、编辑原生配置内容并恢复定义操作 | [Mpack
商店概览](./management-packs/overview.md) |
| 监控 | 使用兼容 Prometheus 的采集、VMAGENT、VictoriaMetrics 和原生 React 监控替换 AMS |
[架构比较](./monitoring/architecture-comparison.md) |
| 用户界面 | 将 React 作为从 Ember 延续而来的运维和管理工作流的主要体验 | [React
用户界面](./frontend/react-ui.md) |
| Java | 统一 JDK 17/Maven 3.9 基线、受管理的框架依赖以及独立的 Ambari/Stack JDK 选择 | [Java
依赖](./platform/java-dependencies.md) |
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/authoring-and-bundling.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/authoring-and-bundling.md
new file mode 100644
index 0000000..4609507
--- /dev/null
+++
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/authoring-and-bundling.md
@@ -0,0 +1,171 @@
+---
+title: 编写管理包与整体打包
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# 编写管理包与整体打包 {#author-and-bundle}
+
+本指南面向[运行时商店预览](./overview.md)的维护者。工具和 schema 应与目标 Server 的实现匹配。参考仓库独立于 Ambari
核心维护，可以按源码或已审核 bundle 的形式分发。
+
+## 安装匹配的工具 {#matching-tool}
+
+开发版 CLI 包要求 Python 3.10 或更高版本。通过匹配的 Ambari 源码检出，在独立环境中安装：
+
+~~~shell
+export AMBARI_SOURCE=/path/to/ambari
+export MPACKSTORE_DIR=/path/to/ambari-mpacks
+python3 -m venv .venv-mpack
+. .venv-mpack/bin/activate
+python -m pip install "$AMBARI_SOURCE/dev-support/mpack"
+ambari-mpack --help
+~~~
+
+示例路径需要替换为本地实际位置。源码包提供 `ambari-mpack` 入口及 schema 校验器；本流程不假设已有等价的公开软件仓库发布包。
+
+## 管理包目录结构 {#package-layout}
+
+~~~text
+example-service/
+ mpack.json
+ LICENSE
+ NOTICE
+ extensions/
+ EXAMPLE/
+ 1.0/
+ metainfo.xml
+ services/
+ EXAMPLE/
+ metainfo.xml
+ configuration/
+ package/
+ scripts/
+ templates/
+~~~
+
+最小扩展包清单可以声明为：
+
+~~~json
+{
+ "schema_version": 1,
+ "type": "full-release",
+ "name": "example-service",
+ "version": "1.0.0.0",
+ "artifacts": [
+ {
+ "name": "example-definitions",
+ "type": "extension-definitions",
+ "source_dir": "extensions"
+ }
+ ],
+ "dependencies": [
+ {
+ "name": "generic-base",
+ "version": "1.0.0.3"
+ }
+ ]
+}
+~~~
+
+扩展及服务描述还必须提供实际兼容的 Stack 上下文、组件名称、分类、数量限制、命令和配置归属。仅有清单示例并不能构成可运行的服务。
+
+可以先生成项目骨架：
+
+~~~shell
+ambari-mpack --json scaffold example-service --directory ./example-service
+~~~
+
+填写真实定义和生命周期实现后，再进行校验与部署，不要直接把未经修改的骨架作为受支持服务发布。
+
+## 构建完整商店 {#build-complete-store}
+
+仓库的 `release.json` 把管理包名称映射到源码路径和准确的定义版本。所选包的清单身份与索引不一致时，构建器会拒绝。命名 profile 位于
`profiles/<name>.json`。
+
+~~~shell
+ambari-mpack --json validate "$MPACKSTORE_DIR/mpacks/nginx"
+ambari-mpack --json build --all \
+ --repository "$MPACKSTORE_DIR" \
+ --output dist \
+ --bundle mpackstore
+~~~
+
+交付物为 `dist/mpackstore.bundle.tar.gz` 和各个独立包归档。Bundle 使用自己的 `bundle.json`
索引与成员摘要，每个成员仍保留独立版本。
+
+只构建已有的基础设施 profile 时：
+
+~~~shell
+ambari-mpack --json build --profile infrastructure \
+ --repository "$MPACKSTORE_DIR" \
+ --output dist-infrastructure \
+ --bundle infrastructure
+~~~
+
+归档身份应不可变。修改内容后发布新版本，不要替换已经分发过的发布 ID 对应字节。构建输出、摘要与所用源码修订应一并保留。
+
+## 通过 CLI 检查与导入 {#cli-import}
+
+填写 Server 基础地址，不要自行附加 API 路径。在交互式终端中，客户端会提示输入密码：
+
+~~~shell
+export AMBARI_SERVER_URL=https://ambari.example.org
+export AMBARI_USERNAME=admin
+ambari-mpack --json import dist/mpackstore.bundle.tar.gz
+ambari-mpack --json list
+ambari-mpack --json services
+~~~
+
+无人值守执行时，通过执行环境的秘密管理机制注入 `AMBARI_PASSWORD`。不要把凭据写入仓库、bundle、命令参数、截图或操作检查点。使用私有
CA 时，提供 CLI 的 `--ca-file` 选项。
+
+目录服务 ID 是准确的提供方和上下文身份，不是服务显示名称。为已有集群选择服务时，可先查看 dry-run 结果：
+
+~~~shell
+ambari-mpack --json enable "$CATALOG_SERVICE_IDS" \
+ --cluster-id "$CLUSTER_ID" \
+ --dry-run
+~~~
+
+使用当前目录返回的 ID，并用逗号分隔多项选择。省略集群 ID 选项表示新建环境。CLI 的 enable
操作负责准备定义和部署交接，主机安装仍由正常部署流程执行。
+
+## 编写生命周期与观察契约 {#lifecycle-contracts}
+
+按服务实际元数据和运行时实现安装、配置、启停、状态查询与服务检查。区分只读状态检查和有副作用的命令，保留受管理身份与持久数据，并区分首次安装和已有的其他业务安装。
+
+通过结构化观察核对准确的主机、组件、软件版本、执行身份和结果。可读日志用于诊断，不能替代原生状态或与任务相匹配的回执。
+
+在线包 hook 必须声明 `scope: "DEFINITIONS"`，并遵守声明的资源范围。省略范围或声明 Server
级范围时，会拒绝在线执行，但仍可导入登记。这项声明并不是安全沙箱。
+
+不要仅为了让服务可选就复制现有 Stack 提供方。应声明 Server 和 UI 所需的依赖、兼容上下文、拥有的配置类型及通用组件元数据。
+
+## 为断网主机准备软件 {#disconnected-hosts}
+
+商店 bundle 交付管理定义。离线部署还需要各服务的完整运行时输入：
+
+- 与目标架构相符的 OS 软件仓库和软件包。
+- 固定的上游归档，或按包说明准备的可验证预置缓存。
+- 使用独立 Python 环境时需要的 wheels 和 constraints。
+- 符合各服务要求的 Java 运行时。
+- 需要源码构建时使用的源码、工具链和模块输入。
+- 可访问的外部数据库及协调服务。
+
+缓存路径和摘要规则以各包的 README 与源码元数据为准。为了使用另一份归档而关闭摘要检查，会改变安装契约。完整软件镜像和断网验收，与生成体积较小的商店
bundle 是不同工作。
+
+## 维护者验收清单 {#maintainer-acceptance}
+
+校验清单与依赖闭包，构建所选归档，检查许可和来源，导入测试
Server，选择准确的服务，并在主机部署前确认交接。除了成功的安装、启动和检查路径，还应覆盖缺失前提、无效配置、操作中断、过期身份和重试等代表性失败。
+
+定义更新应保留已有编辑内容和数据。正在使用的组件模型若发生不支持的变化，应在实现迁移前明确拒绝。参见[完整内容配置](./content-configuration.md)和[恢复语义](./operations-and-recovery.md)。
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/content-configuration.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/content-configuration.md
new file mode 100644
index 0000000..6dffe19
--- /dev/null
+++
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/content-configuration.md
@@ -0,0 +1,111 @@
+---
+title: 编辑完整配置文件
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# 编辑完整配置文件 {#edit-complete-configuration-files}
+
+参考服务包优先使用 `content`
属性管理完整的原生配置文档。这样可以保留应用选项、注释和上游新增设置，不必等每个设置都有独立表单字段。对旧安装使用该流程前，先确认[预览范围](./overview.md)。
+
+## 配置文件与基本设置 {#files-and-basic-settings}
+
+打开服务的 **Configs** 页面。这些包默认进入 **Configuration Files**；**Basic Settings**
保留安装输入、管理身份、监听设置、凭据和管理操作参数。页面不会为了凑一个标签而展示空的 Advanced 页签。
+
+| 服务 | 参考包提供的配置文档 |
+| --- | --- |
+| PostgreSQL | `postgresql.conf`、`pg_hba.conf`、`pg_ident.conf` |
+| Nginx | `nginx.conf` |
+| Kyuubi | `kyuubi-defaults.conf`、环境变量赋值、`log4j2.properties` |
+| Trino |
`config.properties`、`node.properties`、`log.properties`、`jvm.config`、catalog 文档 |
+| Doris | `fe.conf` 与 `be.conf` |
+| Elasticsearch | `elasticsearch.yml`、JVM 选项、`log4j2.properties` |
+| MinIO | `minio.env` 赋值 |
+| Airflow | `airflow.cfg` 与 `webserver_config.py` |
+| Celeborn | `celeborn-defaults.conf`、环境变量赋值、`log4j2.properties` |
+| DolphinScheduler | 各角色的 `application.properties`、`common.properties`、Logback
与 JVM 文档 |
+
+
+
+当前内容控件是多行文本编辑器。能够管理完整文档，并不代表已经提供 IDE 式文件树、语法编辑器或通用的应用配置校验器。
+
+## 推荐编辑流程 {#editing-workflow}
+
+1. 选中正确的服务、配置组和当前版本。
+2. 修改内容前，检查**基本设置**和受管理的路径、监听配置。
+3. 编辑完整文档，保留必要的 include 和模板占位符。
+4. 保存新的配置版本，并填写有意义的备注。
+5. 执行所需重启，或使用服务支持的 reload 命令。
+6. 检查任务结果及应用实际生效的配置。
+7. 重新打开该配置版本，确认保存的文档符合预期。
+
+保存 Ambari 版本和让进程加载配置是两个步骤。提示需要重启，不表示保存失败；仅保存成功也不能证明进程已经加载文件。
+
+## 管理字段与原生格式 {#managed-values-and-formats}
+
+应用设置可以与管理层控制的身份、监听和路径值共同存在。管理包会单独补充这些默认值，用户声明发生冲突时应明确失败，而不是悄悄覆盖管理契约。
+
+Properties 文档保留注释、续行、转义和应用表达式；INI、YAML 使用各自的原生结构。环境文档接受字面量 `NAME=value` 或
`export NAME=value` 赋值，不执行任意 Shell 程序。
+
+React 保存和 Blueprint 内容处理会保留尾部空格与空行，渲染器在需要时补充末尾换行。能够输入文本，不表示任意 Shell
命令、未实现的运行模式或拓扑变更已经得到支持。
+
+## 已有安装与定义更新 {#existing-installations}
+
+对于受支持的标量到 content 迁移，Configs 按当前已保存的值和声明的文件格式生成候选文档，在保存前仍属于待提交修改。已有的 content
不会根据包默认值重新生成，历史版本也会保留。
+
+存在标量配置组覆盖或密码类型属性时，会跳过自动转换。这些情况继续使用旧运行时表示，直到管理员同时、有计划地转换默认组和其他组。完整文件覆盖会替换整份文档，不会像独立属性那样逐行继承。
+
+旧 PostgreSQL 和 Nginx 定义不一定在 Ambari 中保存了主机上的完整配置。新的 content
是安装模板，不会自动发现已定制的主机文件。对这样的实例启用完整内容管理前，应先把实际文件内容放入编辑器；新 content 类型不存在时，旧运行路径仍可使用。
+
+## Nginx 示例 {#nginx-example}
+
+可以在已有 server 块内部加入一个小型验证 location：
+
+~~~nginx
+location /docs-check {
+ return 200 "managed configuration\n";
+}
+~~~
+
+保留完整文档中的其他内容，尤其是 `conf.d` 下管理健康检查文件的 include。保存后，如果组件提供该命令，执行 `RELOAD`。包会先用
`nginx -t` 校验候选配置，再替换主文件；reload 验证会检查健康响应及新 Worker 提供的准确配置摘要。
+
+校验失败时，应查看任务错误并修正候选配置，不要对同一份无效文件反复重启。
+
+## PostgreSQL 示例 {#postgresql-example}
+
+在完整文档中修改已有设置：
+
+~~~properties
+work_mem = '8MB'
+~~~
+
+保存并完成所需重启后，通过数据库原生查询验证：
+
+~~~sql
+SHOW work_mem;
+~~~
+
+保留模板中的路径、端口占位符和本地 peer 管理连接。修改数据目录占位符不会迁移数据库数据。管理包通过服务端可执行文件执行 `postgres -C`
风格的原生配置检查，并在激活时核对加载路径、端口和原生错误视图。
+
+## 校验失败与恢复 {#validation-and-recovery}
+
+Nginx 和 PostgreSQL 会在替换前验证候选文件，并保留此前的字节内容以便恢复。暂存布局包含未修改的资源，使相对 include
能够解析。单个文件替换是原子的，但多个文件整体并不是崩溃原子的数据库事务。
+
+激活失败时可以恢复之前的文件；PostgreSQL 会先停止失败的激活，再恢复配置。发现外部并发修改时会明确报出核对失败。手工恢复前应检查任务及保留的
`.ambari-before` 文件。
+
+配置回退不会回退应用数据或数据库迁移，仍需要独立的数据备份和迁移流程。管理包操作与服务任务的区别见[操作与恢复](./operations-and-recovery.md)。
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/operations-and-recovery.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/operations-and-recovery.md
new file mode 100644
index 0000000..981cdcc
--- /dev/null
+++
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/operations-and-recovery.md
@@ -0,0 +1,128 @@
+---
+title: 管理包操作与恢复
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# 管理包操作与恢复 {#mpack-operations-recovery}
+
+在管理包的**操作记录**中跟踪定义变更，在 Ambari 正常的请求、任务页面中跟踪主机安装和服务操作。两种记录的身份与完成条件不同。
+
+以下说明适用于[运行时预览](./overview.md)，不适用于手工修改 Server 资源目录或数据库记录的做法。
+
+## 理解操作阶段 {#operation-phases}
+
+| 阶段 | 含义与下一步 |
+| --- | --- |
+| `ACCEPTED` | 持久化提交已存在，等待处理 |
+| `PREPARING` | 正在准备候选资源和前提条件 |
+| `WAITING_MAINTENANCE` | 检查影响范围、阻塞项和所需维护操作 |
+| `WAITING_RESTART` | 需要真正重启 Server，按该操作的重启流程处理 |
+| `PUBLISHING` | 正在发布已验证的定义视图 |
+| `SUCCEEDED` | 使用部署交接前，核对操作身份与实际结果 |
+| `FAILED` | 检查准确错误和回执，判断是否需要新计划或符合条件的重试 |
+| `RECOVERY_REQUIRED` | 结果仍未确定，先核对已有回执再决定后续操作 |
+| `CANCELLING` | 正在核对取消过程，尚未完成 |
+| `CANCELLED` | 已按 Server 验证过的策略完成取消 |
+
+HTTP 202 只表示已接受，不表示已完成。超时、响应缺失、日志文字或未知状态，都不能直接当作成功。
+
+## 断开后保留操作身份 {#preserve-identity}
+
+提交前保留准确的 `plan_id`、`plan_digest` 和幂等键。得到响应后，也要保留 `operation_id` 与
`generation`。浏览器按当前账号保存待确认的提交检查点，并在接受结果不确定时提供核对入口。
+
+以相同用户、计划和键重放，会返回原来的操作。丢失响应后另造一个键或计划，可能产生另一项工作，应先核对原提交是否被接受。已经明确拒绝的过期计划可以重新预览。
+
+共享操作历史与另一个账号的本地检查点不是一回事，不要通过复制他人的浏览器检查点或凭据来强行恢复。
+
+## 使用 CLI 查看状态 {#inspect-cli}
+
+使用[编写与打包](./authoring-and-bundling.md#cli-import)中介绍的匹配 CLI，并替换为实际记录的操作 ID：
+
+~~~shell
+ambari-mpack --json operations list
+ambari-mpack --json operations show "$OPERATION_ID"
+ambari-mpack --json operations members "$OPERATION_ID"
+~~~
+
+检查阶段、错误码、受影响范围、成员身份和 hook 回执。诊断信息用于解释问题，自动化判断则必须使用结构化字段和准确标识。
+
+## 核对、重试与取消 {#recovery-actions}
+
+**核对恢复**要求 Server 确定已经发生的事情，不会盲目重新执行 hook：
+
+~~~shell
+ambari-mpack --json operations recover "$OPERATION_ID"
+~~~
+
+**重试**用于符合条件的失败 hook，要求有权威的未产生效果观察，并支持幂等执行：
+
+~~~shell
+ambari-mpack --json operations retry "$OPERATION_ID"
+~~~
+
+**取消**取决于已经保留的效果与当前操作状态：
+
+~~~shell
+ambari-mpack --json operations cancel "$OPERATION_ID"
+~~~
+
+应根据观察到的状态选择动作。这些命令是不同选项，不能作为脚本依次全部执行。已产生或尚未确定的效果可能阻止取消、重试；已完成的效果不会重放。取消中断后继续的是取消流程，不会重新开始原来的安装或更新。
+
+## 维护范围与并发 {#scoped-maintenance}
+
+耗时的准备、验证和 hook 子进程工作放在独占发布锁之外。协调器保护最终视图切换及持久化，预留机制只阻止受影响的定义消费者和相关服务、配置、拓扑变更。
+
+无关的普通写操作和任务可以继续，但这不表示所有管理包发布都能并发，也不表示两个冲突变更可以同时修改同一定义。共享 Stack/版本可能影响多个集群。
+
+阻塞任务由集群、请求、任务 ID 和权威状态标识。已有任务保留兼容的资源引用。活跃 Stack 升级或不支持的在用组件模型变化可能导致计划被拒绝；重启
Server 不能替代尚未实现的组件迁移。
+
+## 区分定义、软件、配置和数据 {#different-change-types}
+
+| 变更 | 实际修改的对象 | 仍可能需要单独完成的工作 |
+| --- | --- | --- |
+| 导入新版 bundle | 登记更多定义版本 | 显式选择并激活版本 |
+| 更新活跃定义 | 脚本、元数据和管理资源绑定 | 升级主机软件或迁移组件 |
+| 保存 content | 创建 Ambari 配置版本 | Reload、重启与原生验证 |
+| 退役或卸载定义 | 移除符合条件的定义归属和可用性 | 显式退役服务并落实数据策略 |
+| 恢复应用数据 | 服务自身的数据状态 | 经验证的备份恢复流程 |
+
+其他包、绑定、操作、服务或集群仍在使用资源时，移除可能失败。旧版本记录也可能为追溯而保留。不要通过删除 Server 目录或数据库行绕过引用检查。
+
+参考包在停止和定义退役时保留用户持久数据，但这不是通用回滚引擎。PostgreSQL
声明的备份恢复操作有自己的隔离目标和结果观察规则，不能推广为每个服务都具备相同能力。
+
+## 按现象排查 {#troubleshooting}
+
+| 现象 | 首先检查 | 恢复方向 |
+| --- | --- | --- |
+| 看不到管理包入口 | 当前账号及管理员授权 | 使用授权账号，直接访问 URL 也不能绕过 Server 权限 |
+| 导入成功，但主机上没有应用 | 服务选择与部署交接 | 继续创建集群或添加服务向导 |
+| 服务不可用 | 目录原因和兼容的 Stack 上下文 | 修正依赖或目标定义，再刷新目录 |
+| 多项服务无法一起选择 | 准确 Stack 上下文与目标集群 | 按兼容环境分组部署 |
+| 提交响应丢失 | 已保存的计划、键和操作记录 | 核对原提交 |
+| 计划以 `STALE_PLAN` 拒绝 | 目录修订及变化的前提 | 明确拒绝后重新预览 |
+| 移除时报 `RESOURCE_IN_USE` | 资源引用关系 | 通过受支持的生命周期操作解除实际使用 |
+| 一直处于 `WAITING_RESTART` | 是否真正重启 Server，以及后续操作观察 | 完成规定的重启与核对步骤 |
+| 包操作成功，但安装失败 | 主机请求、任务和原生观察 | 修复主机前提或配置，不要盲目重新导入 |
+| 所有图表都没有数据 | 时间范围、刷新状态、数据源和近期目标观察 |
按[监控指南](../monitoring/queries-and-dashboards.md#workspace-interactions)处理 |
+
+## 报告中应保留的证据 {#report-evidence}
+
+记录 Server/Agent 构建、包名称和版本及摘要、准确计划与操作身份、受影响集群、观察到的阶段和错误码、相关任务
ID、软件观察，以及已经尝试的恢复动作。配置问题应附脱敏差异和配置版本身份。
+
+不要把密码、令牌、Cookie、数据库连接秘密或私钥放进报告和截图。包成功记录、服务任务结果和监控查询结果应分别标识。
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/overview.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/overview.md
new file mode 100644
index 0000000..5830a4a
--- /dev/null
+++
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/overview.md
@@ -0,0 +1,86 @@
+---
+title: Mpack 商店概览
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# Mpack 商店概览 {#mpack-store-overview}
+
+mpack 商店是独立维护的 Ambari 服务定义与生命周期脚本集合。分发方可以把选定的发布版本打成一个
`mpackstore.bundle.tar.gz`。管理员整体导入后，再通过 Ambari 的正常部署向导选择要管理的服务。
+
+:::info 开发快照
+本组文档描述 2026-09-29 检查的 `AMBARI-26663` 开发实现，包括 Ambari 提交 `3a71190847` 和参考商店提交
`c10a271`。使用前需确认构建包含该实现。3.1 文档仍为预览版，这些快照不代表 ASF
正式发布或生产支持矩阵。参见[源码基线](../release-baseline.md#runtime-mpack-follow-up)。
+:::
+
+## 商店包含什么 {#store-contents}
+
+完整商店 bundle 用于运输独立版本的管理包、清单、服务描述、配置定义和安装管理脚本。参考快照共包含十一个包：一个基础包和十项可选择的服务。
+
+主机软件来自各包声明的软件仓库、经校验的二进制归档、Python
依赖或固定源码构建。导入商店不会把全部运行时软件下载到每台主机；应在安装前准备好这些来源，断网环境尤其如此。
+
+| 对象 | 用途 | 示例 |
+| --- | --- | --- |
+| Bundle | 一次运输多个独立管理包 | `mpackstore.bundle.tar.gz` |
+| 管理包发布版本 | 标识不可变的管理定义 | `nginx/1.0.1.1` |
+| Stack 上下文 | 定义服务可以绑定的环境 | `GENERIC/1.0` 或 `BIGTOP/3.3.0` |
+| 目录服务 ID | 在部署计划中选择准确的提供方和上下文 | 服务目录返回的 ID |
+| 服务描述版本 | 提供服务元数据中的版本标签 | `metainfo.xml` 中的版本 |
+| 软件版本 | 标识主机上安装的应用 | Trino `483` |
+| 操作 | 跟踪持久化的管理包变更及恢复 | 操作 ID 和权威阶段状态 |
+
+服务名称旁的版本来自描述元数据，不能替代对已安装软件版本的实际观察。例如 Kyuubi 的描述版本可以是 `1.0`，而参考运行时是
`1.9.4`。选择器里的包版本标识管理定义。修改包内脚本本身，不会自动升级应用二进制或数据库结构。
+
+## 从导入到运行的完整流程 {#end-to-end-flow}
+
+| 阶段 | 需要确认的结果 |
+| --- | --- |
+| 获取与检查 | Bundle 的分发方、版本和摘要符合预期 |
+| 上传与导入 | 管理包版本出现在目录中，尚未部署主机软件 |
+| 选择服务与目标 | 每项服务只选一个提供方，且目标环境兼容 |
+| 启用定义 | 管理包操作达到经验证的成功状态 |
+| 使用向导部署 | 主机分配和配置产生成功的安装、启动任务 |
+| 执行服务检查 | 服务正确响应，检查结果属于实际执行的请求 |
+| 日常管理 | 编辑配置、查看告警、执行已声明的生命周期命令 |
+
+导入包含多项服务的 bundle 不会自动选择全部服务。Server 会为所选服务解析必要的管理包依赖和绑定；部署前提条件仍需要管理员提供。
+
+新集群的交接进入创建集群流程；兼容已有集群的交接进入添加服务流程，并保留所选服务。服务定义操作成功，不代表随后的软件安装已经完成。
+
+## 管理权限与影响范围 {#administration-and-scope}
+
+管理包入口属于 Ambari 管理员功能。运行时接口要求已认证的管理员身份以及 `AMBARI.MANAGE_STACK_VERSIONS`
权限。服务部署和后续生命周期操作仍遵守各自的权限与校验规则。
+
+商店在一台 Ambari Server 内全局可见。定义按准确的 Stack
名称和版本共享绑定，并不为每个集群提供独立的定义版本。因此，更新定义可能影响使用同一上下文的多个集群，需要检查计划中的受影响集群与维护要求。
+
+管理包操作会预留受影响的定义范围，不涉及该范围的普通写操作和任务可以继续执行。这不意味着服务定义正在替换时，仍可并发执行与其冲突的服务、配置或拓扑变更。参见[操作恢复](./operations-and-recovery.md)。
+
+## 按任务选择阅读路径 {#reading-paths}
+
+- 部署人员：先阅读[商店使用流程](./store-guide.md)，再检查[服务前提条件](./service-catalog.md)。
+- 修改服务配置的管理员：阅读[完整内容配置指南](./content-configuration.md)。
+- 管理包维护者：阅读[编写与整体打包](./authoring-and-bundling.md)。
+- 处理失败或中断的操作人员：阅读[操作与恢复](./operations-and-recovery.md)。
+- Web
用户：阅读[工作区导航与外观](../frontend/workspace-and-appearance.md)和[监控交互](../monitoring/queries-and-dashboards.md#workspace-interactions)。
+
+## 当前能力边界 {#current-boundaries}
+
+参考验收环境为带 systemd 的 Rocky Linux 8 / aarch64。各服务对
Java、Python、数据库、软件仓库和网络的要求不同。仓库中保留了其他平台的定义，并不等于已验证那些平台上的部署。
+
+首批服务包主要覆盖基础安装、配置、启停和服务检查。高可用、自动故障转移、拓扑扩容、软件升级、数据库迁移与生产安全能力因服务而异，不能默认具备。安装服务也不会自动接入它的
exporter 和仪表盘。
+
+运行时商店流程与旧版 `ambari-server install-mpack`
的清单和激活行为不同。混用旧说明前，请先阅读[管理包兼容性入口](../ambari-design/stack-and-services/management-packs.md)。
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/service-catalog.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/service-catalog.md
new file mode 100644
index 0000000..49fb571
--- /dev/null
+++
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/service-catalog.md
@@ -0,0 +1,89 @@
+---
+title: 参考服务目录
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# 参考服务目录 {#reference-service-catalog}
+
+本矩阵描述[运行时 mpack 预览实现](./overview.md)配套的独立参考商店快照 `c10a271`。管理包版本来自
`release.json`，它们属于定义版本，与上游软件版本及 Ambari 自身版本分别管理。
+
+## 管理包与软件版本 {#packages-and-software}
+
+| 管理包 | 定义版本 | 软件基线 | 适用环境 |
+| --- | --- | --- | --- |
+| generic-base | `1.0.0.3` | 基础定义，不部署应用 | `GENERIC/1.0` |
+| nginx | `1.0.1.1` | 操作系统仓库软件包 | `GENERIC/1.0` |
+| postgresql | `1.0.1.1` | 操作系统仓库软件包，参考部署使用 PostgreSQL 10 | `GENERIC/1.0` |
+| kyuubi | `1.0.1.0` | Apache Kyuubi 1.9.4 | `BIGTOP/3.3.0` |
+| airflow | `1.0.1.0` | Apache Airflow 3.3.2 | `GENERIC/1.0` |
+| celeborn | `1.0.1.0` | Apache Celeborn 0.7.0 | `BIGTOP/3.3.0` |
+| dolphinscheduler | `1.0.1.0` | Apache DolphinScheduler 3.1.9 |
`BIGTOP/3.3.0` |
+| trino | `1.0.1.0` | Trino 483 | `BIGTOP/3.3.0` |
+| doris | `1.0.1.0` | Apache Doris 4.1.4 | `BIGTOP/3.3.0` |
+| elasticsearch | `1.0.1.0` | Elasticsearch 9.5.4 | `GENERIC/1.0` |
+| minio | `1.0.1.0` | MinIO `RELEASE.2025-10-15T17-29-55Z` | `GENERIC/1.0` |
+
+基础定义通过管理包依赖引入，不是需要额外部署的应用。Nginx 和 PostgreSQL 不要求安装 Hadoop。通用环境服务与 BIGTOP
服务不能仅因为放在同一个 bundle 中，就任意组合到同一种环境。
+
+## 拓扑与安装前提 {#topology-and-prerequisites}
+
+| 服务 | 首版拓扑 | 安装前需要准备 |
+| --- | --- | --- |
+| Nginx | 一个受管理服务实例 | OS 软件包、配置及 include 路径、可用的受管理监听端口 |
+| PostgreSQL | 一个受管理数据库实例 | OS 软件包、持久化数据目录、本地管理连接和备份 |
+| Kyuubi | Server 与 Client 定义 | JDK 17、匹配的 Spark 3.5 / Scala 2.12 二进制、Hadoop
客户端及 ZooKeeper 配置 |
+| Airflow | 单主机，使用 LocalExecutor | Python 3.11、外部 PostgreSQL 14-18
数据库、数据库用户和管理员信息 |
+| Celeborn | 一个 Master 和至少一个 Worker | JDK 17、固定的官方归档、存储路径与角色端口 |
+| DolphinScheduler | 单主机托管 Master、Worker、API 和 Alert 进程 | 外部 PostgreSQL
14-18、ZooKeeper、Java 11 或 17，以及管理员信息 |
+| Trino | 一个 Coordinator，可配置 Worker | 每台目标主机上的 Java 25、固定归档、节点和数据路径及端口 |
+| Doris | 一个 FE 和一个 BE，可同机或分开 | ARM64 归档、Java 17、数据目录、足够的下载解压空间和显式凭据 |
+| Elasticsearch | 单节点，认证和 HTTPS | 官方 Linux/ARM64 归档、内核及 OS 前提、数据目录和受保护的管理员输入 |
+| MinIO | 一个源码构建的 Server 和 Console | 固定源码、Go 1.24.8 工具链、模块来源或缓存、持久存储和新的 root
凭据 |
+
+参考 PostgreSQL 服务使用的版本为 10，不能满足 Airflow 或 DolphinScheduler 的 PostgreSQL 14-18
要求。需要单独准备合适的外部数据库，不能认为勾选 PostgreSQL 卡片就补齐了前提条件。
+
+Doris 记录的归档约 4.35 GB，展开后约 6.8 GB，尚不包含服务数据。应为下载、解压、旧安装、元数据和应用数据预留空间，商店 bundle
的大小不能作为容量估算。
+
+## 各服务的初始化要点 {#service-initialization}
+
+**Airflow：** 安装会创建独立 Python 环境，只初始化空的专用数据库，并验证管理员设置。已有 schema 会被检查，不会自动升级。声明的
`INITIALIZE_DATABASE` 和 `CREATE_ADMIN` 操作保留用于显式恢复。还应验证专用健康工作流。首版固定为
LocalExecutor，仅在文件中改为其他执行器，不会自动提供 Celery Worker 或消息代理部署。
+
+**DolphinScheduler：** 管理的伪集群使用外部持久化 PostgreSQL schema 与 ZooKeeper，不采用上游
standalone 的内存 H2 和测试 ZooKeeper。空 schema 的归属检查、初始化和管理员设置属于受管理生命周期，不要把非空的其他业务
schema 当作初始化目标。
+
+**Kyuubi：** 管理包固定使用官方二进制，并提供工具把它封装为兼容 RPM。正常的二进制打包路径不会从源码编译
Kyuubi。启动引擎前，需要配置匹配的 Spark/Hadoop 依赖。
+
+**Trino：** Java 25 是服务自身的前提，即使 Ambari 的 Java 基线是 17。内置 TPCH catalog
用于验证；Hive、Iceberg、认证、TLS 和生产资源组都需要显式配置并验证。
+
+**MinIO：** 当前参考实现可通过固定源码构建安装，早期不可安装的草稿已被替代。构建会验证源码和可复现二进制摘要。商店中不附带 MinIO
软件二进制；制作分发内容时，应检查其上游 AGPL-3.0 许可与源码分发要求。
+
+## 服务检查能证明什么 {#service-checks}
+
+服务检查使用软件原生观察。典型例子包括 Kyuubi 引擎和会话操作、Airflow 健康 DAG 结果、Celeborn Worker
注册、DolphinScheduler 认证后的进程状态、Trino TPCH 查询、Doris 临时表写读、Elasticsearch
认证后的集群检查，以及 MinIO 对象写读与清理。
+
+临时测试资源属于准确的执行实例。进程存在、下载成功或命令退出码为零，并不足以证明所有检查通过。应查看 Ambari 请求、任务结果和软件的结构化观察。
+
+基础检查通过，不代表高可用、安全加固、备份恢复、生产容量或任意连接器兼容性已经通过。
+
+## 能力边界与扩展工作 {#limits-and-extension-work}
+
+参考首版不承诺高可用或自动故障转移。Airflow CeleryExecutor、MinIO 分布式存储、Celeborn HA、Doris
复制和云模式、自动数据库迁移以及生产连接器集成都需要另外实现和验收。
+
+停止服务或退役定义，不表示要求删除用户持久化数据；删除定义仍可能因正在使用而被阻止。修改绑定前先阅读[操作语义](./operations-and-recovery.md)。
+
+十项服务均提供[完整配置文档编辑](./content-configuration.md)。专属服务指标是独立能力，仅有 Linux
主机指标并不能证明已经具备服务级监控覆盖。
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/store-guide.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/store-guide.md
new file mode 100644
index 0000000..5ec4878
--- /dev/null
+++
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/management-packs/store-guide.md
@@ -0,0 +1,90 @@
+---
+title: 导入商店并部署服务
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# 导入商店并部署服务 {#import-store-deploy-services}
+
+本流程使用[运行时 mpack 预览实现](./overview.md)。从与开发构建配套的分发方取得审核过的
bundle，或[通过参考仓库自行打包](./authoring-and-bundling.md)。
+
+## 开始前的准备 {#before-you-start}
+
+需要管理员账号、已启用的运行时 mpack API、匹配的 Server/Agent 构建，以及可核对摘要的
bundle。为计划选择的服务准备可访问的软件来源、所需数据库、Java/Python
运行时、可写数据目录和可用端口。分配主机前先阅读[服务矩阵](./service-catalog.md)。
+
+替换已启用定义前，记录当前包版本、受影响集群配置和数据备份安排。服务定义归档不能替代数据备份。
+
+## 找到管理包入口 {#open-management-packs}
+
+在集群工作区，从侧栏上方进入**管理包**，位置在 Ambari 品牌与全局集群入口下方。已经进入全局目录时，使用顶部导航中的**管理包**。
+
+页面分为**服务目录**、**已导入包**和**操作记录**。浏览目录时，右侧保留已选服务面板。**返回工作区**可恢复之前离开的集群页面及其 URL 参数。
+
+
+
+这张开发环境截图使用中文界面和暗色外观。其中主机名、数量和版本是截图时的测试环境数据。
+
+## 导入完整 Bundle {#import-the-bundle}
+
+1. 点击**导入管理包**，打开上传对话框。
+2. 选择 `mpackstore.bundle.tar.gz`，等待检查并识别成员包。
+3. 核对成员后执行**导入管理包**。完整商店导入会包含检查到的全部成员。
+4. 在**操作记录**中查看进度。浏览器或网络断开时，保留操作 ID。
+5. 导入成功后返回**服务目录**。
+
+导入只登记管理包，不绑定服务定义、不执行激活 hook，也不向主机部署软件。默认上传协议限制为压缩后 256 MiB、展开后 1 GiB、最多
100,000 个条目；实际限制应以所用 Server 构建为准。
+
+离线安装应按各服务要求准备软件仓库和缓存，不要仅为了离线安装就把数 GB 的软件发行包塞进商店 bundle。
+
+## 每项服务选择一个版本 {#select-one-version}
+
+可以按服务或包搜索，也可以使用环境选择器缩小范围。目录按服务和准确的 Stack 上下文聚合，同组历史版本放进一个选择器，不再重复铺满页面。
+
+默认优先选用当前已启用的定义。其他数字型定义版本按版本排序，但版本号更大并不代表已验证兼容或支持升级运行时软件。切换前应阅读该管理包的发布说明。
+
+勾选服务后，它会进入**已选服务**面板。切换版本会替换该组已选择的提供方。右侧显示准确的管理包发布版本，而不只是软件名称；不需要的服务也可以在这里移除。
+
+与当前选择或部署目标不兼容的服务会禁用并显示原因。清空或调整选择后，可以切换到另一种环境。筛选目录不会自动移除已选服务。
+
+## 选择部署目标 {#choose-a-destination}
+
+在**部署位置**中选择**新建集群**或兼容的已有集群，然后点击**继续部署所选服务**。
+
+Server
会解析必需的提供方和绑定。计划可能要求确认维护或重启，应检查受影响集群和相应要求。简单的启用操作可以不额外弹出确认框直接继续；两种路径都会生成持久化操作。
+
+**定义已启用**表示管理定义已经可用，不等于主机上已经安装并运行了服务。
+
+## 完成部署向导 {#complete-the-deployment}
+
+启用操作经验证成功后，使用页面提供的**创建集群**或**添加服务到集群**入口。在向导中：
+
+1. 核对所选服务及依赖。
+2. 把组件分配到满足要求的主机。
+3. 填写必要的凭据、数据库地址、软件位置和配置。
+4. 复核分配结果并开始安装。
+5. 检查安装、启动任务和服务检查，再进入服务 Summary 与 Configs 页面。
+
+安装任务失败与管理包操作失败应分别处理。操作 ID 和部署请求、任务 ID 属于不同流程，排查问题时应同时保留。
+
+## 恢复时避免重复提交 {#recover-without-duplicates}
+
+如果无法确定提交是否被接受，使用页面的核对恢复入口。它会复用已保留的计划与提交身份，不会把超时直接当作“什么都没发生”。
+
+如果计划过期或输入改变，并且已明确拒绝接受，应重新预览。如果操作在等待任务或维护，先检查准确的阻塞项，再决定如何重试。主机安装失败时，不要通过反复上传同一个
bundle 来恢复。
+
+各阶段含义、CLI 查询方法和恢复限制见[操作与恢复](./operations-and-recovery.md)。
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/monitoring/queries-and-dashboards.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/monitoring/queries-and-dashboards.md
index f392a82..1ee09c6 100644
---
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/monitoring/queries-and-dashboards.md
+++
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/monitoring/queries-and-dashboards.md
@@ -85,6 +85,51 @@ Ambari 将保留的 `cluster` 变量绑定到当前应用集群，并将 `__rate
此运行截图来自[固定版本的三节点监控验证记录](https://github.com/apache/ambari/tree/4e95d2e33493ac934d7d98a14a81d86c0f1bc0c4/docs/frontend-refactor/runtime-evidence/AMBARI-26638)。图中数值仅代表该开发环境，不是容量规划基准。
+## 工作区交互 {#workspace-interactions}
+
+以下交互来自[运行时 mpack 与控制台开发后续版本](../management-packs/overview.md)。应确认所安装的 Web
构建包含这些功能；上文较早的固定监控证据，本身不能证明这些新控件已经提供。
+
+### 刷新与时间范围 {#refresh-and-time-range}
+
+相对时间仪表盘默认每 30
秒刷新。偏好按用户和集群保存，也会保留显式暂停。暂停的视图提供**恢复实时更新**入口。绝对历史时间范围和布局编辑期间，不会自动推进时间。
+
+查询会保留秒精度，不再把结束时间向下截到整分钟。时间序列横轴采用所选查询边界，即使只有一个样本也保持一致。刚安装采集后，应等待首批样本；CPU、吞吐量等速率查询需要足够的观察点才能计算。
+
+### 阅读与操作图例 {#legend-controls}
+
+磁盘吞吐量的一项图例表示一个主机、设备以及读或写方向，并不代表该主机的全部指标。
+
+| 操作 | 效果 |
+| --- | --- |
+| 点击序列名称 | 只切换这一条曲线的显示或隐藏 |
+| 点击**仅看** | 只显示选中的曲线 |
+| 点击**全部显示** | 恢复全部返回的曲线 |
+| 滚动图例 | 浏览其余项目，不必为了放下所有名称而压缩整个绘图区 |
+
+
+
+隐藏项使用划线名称和隐藏图标，数量提示区分正在显示的序列和已返回序列；全部隐藏时有明确说明。颜色和可见性按指标标签及查询目标身份跟随序列，刷新或重排时不会串到其他曲线。“仅看”状态下，新到来的序列保持隐藏。如果所选序列离开结果集，可用**全部显示**查看其他序列。
+
+这些控件只影响展示，采集与存储会继续。开始另一条查询时，会重置该图表的显隐上下文。
+
+### 从图表进入查询 {#chart-to-explorer}
+
+打开面板菜单并选择**查看查询**。Explorer 会接收已经解析的查询、数据源、集群路由和时间范围，核对后再显式执行。
+
+Explorer
区分尚未执行、加载中、有结果、无匹配序列和查询失败。取消会终止正在进行的请求，过期上下文的迟到响应不应覆盖当前结果。修改输入后，在下一次查询完成前，原结果会被标记为上次查询的结果。
+
+通过图表、数据视图切换查看结果。最近查询历史按用户和持久集群身份隔离，浏览器存储失败不妨碍查询。键盘用户可以使用 Ctrl/Command + Enter
运行。
+
+### 检查采集目标与数据源 {#inspect-targets-and-datasources}
+
+采集目标支持按主机、组件或端点筛选、需要关注筛选和详情侧栏。从目标详情点击**查看查询**时，会把准确标签带入 Explorer。
+
+对于托管的 VictoriaMetrics 数据源，页面结合 Ambari 服务发现与已存储的采集成功状态、样本时间和耗时进行展示，不会向存储节点索取另一台
VMAGENT 的目标清单。缺失、冲突、不属于当前作用域或超过五分钟的观察不会显示为健康；没有可靠的近期观察时显示未知。明确采集失败与未知状态不同。
+
+其他数据源保留自身的原生目标元数据行为。不支持元数据接口时会明确说明能力限制，不能把它当作一个成功的空目录。
+
+数据源详情显示作用域、端点和是否已配置认证。**已启用**是配置设置，不是连接测试结果，应分别检查查询链路、发现与采集，以及服务专属指标覆盖。
+
## API 示例 {#api-examples}
以下查询端点相对于 Ambari 通常的 `/api/v1` 基础路径。使用数据源列表中的数据源 ID，而不是仪表盘 ID。保持查询 URL 编码：
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/release-baseline.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/release-baseline.md
index df7677f..b0385bf 100644
---
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/release-baseline.md
+++
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/release-baseline.md
@@ -73,6 +73,25 @@ React 对等基线区分实现、静态比较和运行时验证。较早的审
指南区分最终独立集群包验收与早期带覆盖补丁的托管 HBase 部署证据，并说明真实
KDC、解绑与数据保留、故障注入及消息代理撤权等剩余门禁。[运维指南](./multi-cluster/operations.md#upgrade-and-acceptance-work)列出了发布最终支持声明前仍需补齐的证据。
+## 运行时 Mpack 与控制台后续版本 {#runtime-mpack-follow-up}
+
+运行时商店指南增加了单独标识的开发后续版本，检查日期为 2026-09-29：
+
+| 输入 | 检查的快照 |
+| --- | --- |
+| Ambari 实现 | 分支 `AMBARI-26663`，提交 `3a71190847503b033036833d1d49ba0ce325ca41` |
+| 独立参考商店 | 提交 `c10a271`，准确的定义版本由 `release.json` 选择 |
+| 参考部署范围 | Rocky Linux 8/aarch64、systemd、基础非 HA 服务 |
+| 控制台验收范围 | 桌面环境，覆盖服务聚合选择、完整内容编辑、外观导航和监控交互 |
+
+这些实现快照是在开发检出中检查的，不代表新发布的 Apache 源码标签、可下载的 ASF 二进制发行版，也不能证明每个 3.1
构建都已经包含它们。应取得配套供应的构建和商店，并在使用流程前检查发布的清单与 API 能力。
+
+证据输入包括核心检出中的
`docs/mpack/http-api.md`、`docs/mpack/corrective-implementation.md` 和
`docs/frontend-refactor/react-current`，以及商店的 `release.json`、各服务
README、`docs/content-configuration.md` 和
`docs/content-configuration-acceptance.md`。较晚的完整配置验收记录替代了较早的定义版本示例和不可安装的 MinIO
草稿。
+
+该快照包含十项所选服务的基础运行检查及针对性的配置失败恢复检查，不等于通用高可用、多平台、所有角色、数据迁移或生产负载认证。网站构建和浏览器测试只验证文档行为。
+
+建议先阅读[商店概览](./management-packs/overview.md)、[服务矩阵](./management-packs/service-catalog.md)和[工作区指南](./frontend/workspace-and-appearance.md)。
+
## 发布版本前 {#before-publishing-a-release}
选定发布候选版本后更新此基线。记录最终源代码标签、签名构件/校验和位置、软件包目标矩阵、支持的升级路径、测试结果和发布投票结果。完成这些工作后，才能将预览标记替换为已发布版本。
diff --git
a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/release-notes.md
b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/release-notes.md
index 166010a..3aa45bd 100644
--- a/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/release-notes.md
+++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/version-3.1.0/release-notes.md
@@ -77,6 +77,14 @@ Python 依赖打包采用哈希锁定的构件，明确选择平台和 ABI，检
构建命令与产物检查见 [RPM
打包](./platform/rpm-packaging.md)，完整构建环境见[从源码构建](./ambari-dev/building-from-source.md)。
+## 运行时商店与控制台预览 {#runtime-store-and-console-preview}
+
+单独记录的 AMBARI-26663 开发后续版本增加了整体导入商店、按服务和提供方选择、限定定义维护范围、完整配置文档以及可恢复的管理包操作。导入
bundle 只登记定义，软件安装仍通过正常向导完成。
+
+主控制台还增加了浅色、暗色和跟随系统外观，带原集群页面返回能力的全局导航，聚合的包版本，紧凑主机告警链接，以及明确的监控图例控件。这些功能需要[匹配的开发快照](./release-baseline.md#runtime-mpack-follow-up)。
+
+操作步骤和边界见[管理包商店](./management-packs/overview.md)、[完整配置文件](./management-packs/content-configuration.md)及[工作区导航与外观](./frontend/workspace-and-appearance.md)。本条目不表示发布了在线市场、ASF
二进制商店、自动软件升级或参考服务包的 HA 支持。
+
## 社区改进 {#selected-community-changes}
### 集群操作与配置 {#cluster-operations}
diff --git a/static/img/3.1.0/mpack-store/catalog-dark.jpg
b/static/img/3.1.0/mpack-store/catalog-dark.jpg
new file mode 100644
index 0000000..bce822e
Binary files /dev/null and b/static/img/3.1.0/mpack-store/catalog-dark.jpg
differ
diff --git a/static/img/3.1.0/mpack-store/configuration-files-dark.jpg
b/static/img/3.1.0/mpack-store/configuration-files-dark.jpg
new file mode 100644
index 0000000..76191cc
Binary files /dev/null and
b/static/img/3.1.0/mpack-store/configuration-files-dark.jpg differ
diff --git a/static/img/3.1.0/mpack-store/legend-controls.jpg
b/static/img/3.1.0/mpack-store/legend-controls.jpg
new file mode 100644
index 0000000..443fae8
Binary files /dev/null and b/static/img/3.1.0/mpack-store/legend-controls.jpg
differ
diff --git a/tests/e2e/i18n.spec.ts b/tests/e2e/i18n.spec.ts
index 554adf4..5be80d1 100644
--- a/tests/e2e/i18n.spec.ts
+++ b/tests/e2e/i18n.spec.ts
@@ -168,7 +168,7 @@ test('3.1 preview routes are bilingual and preserve the
stable default', async (
const data = JSON.parse(readFileSync('.docusaurus/globalData.json', 'utf8'));
const versions = data['docusaurus-plugin-content-docs'].default.versions;
const preview = versions.find(item => item.name === '3.1.0');
- expect(preview.docs).toHaveLength(77);
+ expect(preview.docs).toHaveLength(84);
expect(preview.isLast).toBe(false);
expect(versions.find(item => item.name === '3.0.0').isLast).toBe(true);
expect(versions.some(item => item.name === 'current')).toBe(false);
diff --git a/tests/i18n.test.mjs b/tests/i18n.test.mjs
index 5109959..431d48e 100644
--- a/tests/i18n.test.mjs
+++ b/tests/i18n.test.mjs
@@ -119,6 +119,10 @@ test('3.1.0 retains current general documentation without
obsolete tutorial rout
'platform/java-dependencies', 'platform/python-runtime',
'platform/rpm-packaging', 'frontend/react-ui',
'frontend/customizing-react-ui',
+ 'frontend/workspace-and-appearance',
+ 'management-packs/overview', 'management-packs/store-guide',
+ 'management-packs/service-catalog',
'management-packs/content-configuration',
+ 'management-packs/authoring-and-bundling',
'management-packs/operations-and-recovery',
'multi-cluster/architecture', 'multi-cluster/getting-started',
'multi-cluster/managed-dependencies', 'multi-cluster/operations',
'quick-start/installation-guide', 'quick-start/download',
@@ -130,7 +134,7 @@ test('3.1.0 retains current general documentation without
obsolete tutorial rout
'ambari-dev/running-tests', 'ambari-plugin-contribution/index',
];
for (const id of required) assert.ok(ids.includes(id), `Missing supported
documentation: ${id}`);
- assert.equal(ids.length, 77);
+ assert.equal(ids.length, 84);
assert.equal(new Set(ids).size, ids.length);
assert.ok(!ids.some(id => id.startsWith('ambari-design/metrics/') ||
id.startsWith('ambari-plugin-contribution/scom/')));
assert.ok(!ids.includes('ambari-plugin-contribution/step-by-step'));
diff --git
a/versioned_docs/version-3.1.0/ambari-design/enhanced-configs/index.md
b/versioned_docs/version-3.1.0/ambari-design/enhanced-configs/index.md
index a22c88d..97b0850 100644
--- a/versioned_docs/version-3.1.0/ambari-design/enhanced-configs/index.md
+++ b/versioned_docs/version-3.1.0/ambari-design/enhanced-configs/index.md
@@ -41,6 +41,10 @@ The effective form combines Stack defaults, service
configuration metadata, the
Dependency updates are scoped to changed properties. The recommendations
request receives the changed configuration list and returns only affected
dependencies. Invalid metadata, unsupported widget definitions, or values
outside declared constraints must be corrected before saving.
+## Complete Native Documents {#complete-native-documents}
+
+The runtime mpack follow-up uses `content` properties to manage complete
native files for ten reference services, including PostgreSQL and Nginx.
Configuration Files and Basic Settings have different responsibilities:
application documents coexist with managed identities, paths, credentials and
listener inputs. See [Edit Complete Configuration
Files](../../management-packs/content-configuration.md) for migration,
configuration-group inheritance, validation and recovery boundaries.
+
## Save And Reload {#save-and-reload}
Ambari saves the resulting configuration through its normal configuration
APIs. Changes to a theme or Stack definition require restarting Ambari Server
so the metadata is reloaded. Themes are retained in 3.1; the removed legacy
monitoring widget model is unrelated to these configuration-form controls.
diff --git
a/versioned_docs/version-3.1.0/ambari-design/stack-and-services/management-packs.md
b/versioned_docs/version-3.1.0/ambari-design/stack-and-services/management-packs.md
index d022b03..2976975 100644
---
a/versioned_docs/version-3.1.0/ambari-design/stack-and-services/management-packs.md
+++
b/versioned_docs/version-3.1.0/ambari-design/stack-and-services/management-packs.md
@@ -21,6 +21,12 @@ limitations under the License.
# Management Packs {#management-packs}
+:::info Runtime store or legacy installation
+For whole-store import, service selection, complete configuration files, and
durable operation recovery, use the [runtime mpack store
guides](../../management-packs/overview.md). They describe the AMBARI-26663
development follow-up.
+
+The command-line workflow below describes the older setup-time mechanism at
its pinned source revision. Its staging/restart behavior must not be assumed
for every runtime store operation. Use the manifest and tooling expected by the
chosen mechanism; sharing the name `mpack.json` does not establish archive
compatibility.
+:::
+
An Ambari management pack is an archive of stack, service, extension, or view
artifacts plus `mpack.json` metadata. The Server `setupMpacks.py`
implementation expands the archive, reads its metadata, validates
prerequisites, stages the pack, and creates the resources used by the stack
loader.
## Metadata {#metadata}
diff --git a/versioned_docs/version-3.1.0/frontend/react-ui.md
b/versioned_docs/version-3.1.0/frontend/react-ui.md
index e7dbb97..e445526 100644
--- a/versioned_docs/version-3.1.0/frontend/react-ui.md
+++ b/versioned_docs/version-3.1.0/frontend/react-ui.md
@@ -87,6 +87,12 @@ Monitoring routes use `CLUSTER.VIEW_METRICS` for cluster
queries, dashboards, ex
The former standalone dashboard Heatmaps route redirects to
`/main/dashboard/metrics`. This is an intentional replacement boundary: React
does not provide AMS or Ganglia compatibility paths, and the migration does not
claim legacy Heatmaps or AMS/Ganglia behavior as unfinished React work.
+## Workspace Navigation And Appearance {#workspace-navigation-and-appearance}
+
+The AMBARI-26663 development follow-up adds grouped management-pack service
selection, prominent global navigation, return to the previous cluster page,
persistent light/dark/system appearance, compact host alert links, and clearer
monitoring interactions. These capabilities require the corresponding
implementation rather than only the earlier React baseline.
+
+See [Workspace Navigation and Appearance](./workspace-and-appearance.md) for
visible entry points and state boundaries, and the [store
walkthrough](../management-packs/store-guide.md) for importing and deploying
selected services.
+
## Build and Deployment {#build-and-deployment}
The Maven `ambari-web` module builds the primary React application from
`ambari-web/latest` with the configured Node/npm toolchain and writes
`latest/dist`; the Maven package copies that output into the server Web UI
artifact. The separate `ambari-admin` module builds its Admin React application
from `src/main/resources/ui/ambari-admin` and packages its output under
`classes/latest`.
diff --git a/versioned_docs/version-3.1.0/frontend/workspace-and-appearance.md
b/versioned_docs/version-3.1.0/frontend/workspace-and-appearance.md
new file mode 100644
index 0000000..7619109
--- /dev/null
+++ b/versioned_docs/version-3.1.0/frontend/workspace-and-appearance.md
@@ -0,0 +1,84 @@
+---
+title: Workspace Navigation And Appearance
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# Workspace Navigation And Appearance {#workspace-navigation-and-appearance}
+
+This guide describes the console follow-up in the [runtime mpack development
snapshot](../management-packs/overview.md). It focuses on the main React
console and desktop operation. Embedded applications and separately deployed
interfaces may have their own navigation and appearance.
+
+## Global Directories And Cluster Workspaces {#global-and-cluster}
+
+The global navigation has **Clusters**, **Services**, and administrator-only
**Management Packs** entries. Clusters and Management Packs also appear near
the top of a cluster's sidebar, above its dashboard, monitoring, services,
hosts, and alerts.
+
+Use global directories to choose an environment or manage definitions. Use the
cluster workspace for service configuration and operational tasks. The selected
cluster remains explicit in the application header.
+
+
+
+Menu visibility follows account permissions. A hidden administrator menu is
not a missing installation, and manually entering its route does not grant
access.
+
+## Return To The Page You Left {#return-to-workspace}
+
+When you leave a cluster for a global directory, the console records the exact
cluster pathname and query parameters for the current account in the browser
session.
+
+**Return to workspace** opens that recorded page. For example, leaving a
service Configs page, visiting Clusters and Management Packs, then refreshing
the global page can still return to the same service path and URL parameters.
+
+The record is scoped to the account and browser session. A fresh session
without a prior cluster page may have no return action. It restores navigation,
not unsaved form contents. Continue to respect unsaved-change prompts, current
permissions, and whether the cluster/service still exists.
+
+## Choose Light, Dark, Or System {#appearance}
+
+Open **Appearance** using the sun/moon/display icon in the top bar, beside the
language control. The menu is also available on the login page.
+
+| Choice | Behavior |
+| --- | --- |
+| Light | Keep the light console regardless of OS appearance |
+| Dark | Keep the dark console regardless of OS appearance |
+| System | Follow the operating system's light/dark preference |
+
+The explicit choice is a browser preference. It survives reloads and
synchronizes with other tabs on the same origin. It does not modify cluster
configuration or restart services. If browser storage is unavailable, changing
appearance still works in the current tab.
+
+The dark design uses graphite layers with light text and distinct selected
states. IBM Plex Sans is served locally by the application; Chinese text uses
available CJK sans-serif fonts, while configuration documents and code retain
monospace presentation.
+
+Appearance covers the main navigation, tables, configuration controls, common
dialogs, chart axes/legends, status labels and pagination. Keep severity labels
and numbers as well as color when interpreting a state.
+
+## Service Configuration And Version Controls {#configuration-controls}
+
+The service Summary and Configs tabs remain distinct. In Configs, choose the
configuration group and version before editing. Version menus and
configuration-group popup menus use the same active appearance.
+
+The reference store's [Configuration Files
workflow](../management-packs/content-configuration.md) presents full native
documents while retaining Basic Settings for management inputs. Saving a new
version still requires the appropriate configuration permission and any later
restart/reload.
+
+## Host Alert Counts {#host-alert-counts}
+
+A compact badge beside a host name shows the sum of its critical and warning
alerts. Critical alerts take visual precedence; warning-only counts use their
own presentation. Zero totals do not display a badge.
+
+Hover or focus to identify the host and severity breakdown. Activating the
badge opens that host's Alerts page; activating the host name opens its
Summary. The badge uses a normal accessible link and can be activated from the
keyboard.
+
+Host health, maintenance state, pending restarts and alert count are separate
indicators. A host health icon and an alert badge can therefore appear together.
+
+## Monitoring Interactions {#monitoring-interactions}
+
+Use [Queries and
Dashboards](../monitoring/queries-and-dashboards.md#workspace-interactions) for
refresh preferences, second-precision time ranges, query cancellation,
empty/error feedback, target details and series visibility.
+
+The query endpoint, data-collection target and displayed chart are different
layers. Hiding a curve does not stop collection. An enabled datasource is
configuration state, not proof that a connectivity test or every scrape
succeeded.
+
+## Recover From A Stale Browser Page {#browser-recovery}
+
+After a development deployment replaces Web files, reload the page to load the
new application. If an older browser tab still has the prior menus, compare the
actual loaded build before diagnosing a missing feature.
+
+A lost package-submission response must be recovered through its operation
identity, not by repeatedly refreshing and resubmitting. For that workflow use
[management-pack recovery](../management-packs/operations-and-recovery.md).
diff --git a/versioned_docs/version-3.1.0/introduction.md
b/versioned_docs/version-3.1.0/introduction.md
index f7cd0bb..f42e183 100644
--- a/versioned_docs/version-3.1.0/introduction.md
+++ b/versioned_docs/version-3.1.0/introduction.md
@@ -24,6 +24,7 @@ limitations under the License.
| Area | Change in 3.1.0 | Guide |
| --- | --- | --- |
+| Management pack store preview | Import a complete store, select services,
edit native configuration content, and recover definition operations in a
matching development build | [Mpack store
overview](./management-packs/overview.md) |
| Monitoring | Replace AMS with Prometheus-compatible collection, VMAGENT,
VictoriaMetrics, and native React monitoring | [Architecture
comparison](./monitoring/architecture-comparison.md) |
| User interface | Make React the primary experience for the operational and
administrative workflows carried forward from Ember | [React user
interface](./frontend/react-ui.md) |
| Java | Consolidate the JDK 17/Maven 3.9 baseline, managed framework
dependencies, and separate Ambari/Stack JDK selection | [Java
dependencies](./platform/java-dependencies.md) |
diff --git
a/versioned_docs/version-3.1.0/management-packs/authoring-and-bundling.md
b/versioned_docs/version-3.1.0/management-packs/authoring-and-bundling.md
new file mode 100644
index 0000000..74880a3
--- /dev/null
+++ b/versioned_docs/version-3.1.0/management-packs/authoring-and-bundling.md
@@ -0,0 +1,171 @@
+---
+title: Author And Bundle Management Packs
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# Author And Bundle Management Packs {#author-and-bundle}
+
+This guide targets maintainers of the [runtime store preview](./overview.md).
Use tooling and schemas from the same implementation as the destination Server.
The reference repository is maintained separately from Ambari core and can be
distributed as source or a reviewed bundle.
+
+## Install The Matching Tool {#matching-tool}
+
+The development CLI package requires Python 3.10 or later. Install it from the
matching Ambari source checkout into an isolated environment:
+
+~~~shell
+export AMBARI_SOURCE=/path/to/ambari
+export MPACKSTORE_DIR=/path/to/ambari-mpacks
+python3 -m venv .venv-mpack
+. .venv-mpack/bin/activate
+python -m pip install "$AMBARI_SOURCE/dev-support/mpack"
+ambari-mpack --help
+~~~
+
+These paths are examples to replace locally. The source package supplies the
`ambari-mpack` entry point and its schema validator. This procedure does not
assume that an equivalent package has been published to a public package
registry.
+
+## Package Layout {#package-layout}
+
+~~~text
+example-service/
+ mpack.json
+ LICENSE
+ NOTICE
+ extensions/
+ EXAMPLE/
+ 1.0/
+ metainfo.xml
+ services/
+ EXAMPLE/
+ metainfo.xml
+ configuration/
+ package/
+ scripts/
+ templates/
+~~~
+
+A minimal extension-package manifest can declare:
+
+~~~json
+{
+ "schema_version": 1,
+ "type": "full-release",
+ "name": "example-service",
+ "version": "1.0.0.0",
+ "artifacts": [
+ {
+ "name": "example-definitions",
+ "type": "extension-definitions",
+ "source_dir": "extensions"
+ }
+ ],
+ "dependencies": [
+ {
+ "name": "generic-base",
+ "version": "1.0.0.3"
+ }
+ ]
+}
+~~~
+
+The extension/service descriptors must supply the actual compatible Stack
contexts, component names, categories, cardinalities, commands, and
configuration ownership. A manifest example is not a complete runnable service.
+
+To create a starting project:
+
+~~~shell
+ambari-mpack --json scaffold example-service --directory ./example-service
+~~~
+
+Fill in the real definitions and lifecycle implementation before validation
and deployment. Do not publish an unchanged scaffold as a supported service.
+
+## Build The Complete Store {#build-complete-store}
+
+The repository's `release.json` maps each package name to its source path and
exact definition version. The builder rejects a selection whose manifest
identity does not match that index. Named profiles are stored under
`profiles/<name>.json`.
+
+~~~shell
+ambari-mpack --json validate "$MPACKSTORE_DIR/mpacks/nginx"
+ambari-mpack --json build --all \
+ --repository "$MPACKSTORE_DIR" \
+ --output dist \
+ --bundle mpackstore
+~~~
+
+The deliverable is `dist/mpackstore.bundle.tar.gz` plus the individual package
archives. The bundle has its own `bundle.json` index and member digests;
members retain independent versions.
+
+For the existing infrastructure-only profile:
+
+~~~shell
+ambari-mpack --json build --profile infrastructure \
+ --repository "$MPACKSTORE_DIR" \
+ --output dist-infrastructure \
+ --bundle infrastructure
+~~~
+
+Archive identity is immutable. Publish a new version when content changes
rather than replacing bytes behind a previously distributed release ID. Retain
the build output and digests with the source revision used to produce them.
+
+## Inspect And Import Through The CLI {#cli-import}
+
+Use the Server base URL without appending the API path. In an interactive
terminal the client prompts for the password:
+
+~~~shell
+export AMBARI_SERVER_URL=https://ambari.example.org
+export AMBARI_USERNAME=admin
+ambari-mpack --json import dist/mpackstore.bundle.tar.gz
+ambari-mpack --json list
+ambari-mpack --json services
+~~~
+
+For unattended use, inject `AMBARI_PASSWORD` through the execution
environment's secret mechanism. Do not place credentials in the repository,
bundle, command arguments, screenshots, or operation checkpoints. For a private
CA, supply the CLI's `--ca-file` option.
+
+Catalog service IDs are exact provider/context identities, not service display
names. A dry-run selection against an existing cluster can be inspected before
acceptance:
+
+~~~shell
+ambari-mpack --json enable "$CATALOG_SERVICE_IDS" \
+ --cluster-id "$CLUSTER_ID" \
+ --dry-run
+~~~
+
+Use a comma-separated list of IDs returned by the current catalog. Omitting
the cluster-ID option selects a new environment. The CLI's enable operation
prepares definitions and a deployment handoff; the normal deployment workflow
still performs host installation.
+
+## Author Lifecycle And Observation Contracts {#lifecycle-contracts}
+
+Implement installation, configuration, start/stop/status, and service checks
using the service's actual metadata and runtime. Separate read-only status
checks from mutating commands. Preserve owned identities and persistent data,
and distinguish a first installation from an existing unrelated installation.
+
+Use structured observations to verify exact host, component, software version,
execution identity, and result. Human-readable logs are diagnostic evidence,
not a substitute for a native status or a matching task receipt.
+
+Online package hooks must declare `scope: "DEFINITIONS"` and stay within the
declared resource boundary. Omitted or Server-wide hook scope is rejected for
online execution, although import can still register the package. This
declaration is not a security sandbox.
+
+Do not duplicate an existing Stack provider merely to make a service
selectable. Declare the dependencies, compatible contexts, owned configuration
types, and generic component metadata that the Server and UI need.
+
+## Prepare Software For Disconnected Hosts {#disconnected-hosts}
+
+A store bundle delivers management definitions. An offline rollout also needs
every service's runtime inputs:
+
+- OS repositories and packages for the destination architecture.
+- The pinned upstream archive, or the pack's documented verified preloaded
cache.
+- Python wheels and constraints where an isolated Python environment is used.
+- Java runtimes appropriate for each service.
+- Source/toolchain/module inputs where a source build is required.
+- Reachable external databases and coordination services.
+
+Use the exact cache paths and digest rules in each package's README and source
metadata. Disabling checksum verification to use a different archive changes
the installation contract. A full software mirror or air-gapped acceptance run
is separate work from producing a small store bundle.
+
+## Maintainer Acceptance Checklist {#maintainer-acceptance}
+
+Validate the manifest and dependency closure, build the selected archives,
inspect licenses and provenance, import into a test Server, select only the
intended services, and verify the handoff before host deployment. Exercise
successful install/start/check paths and representative failures, including
missing prerequisites, invalid configuration, interrupted work, stale
identities, and retries.
+
+Definition updates must preserve existing edited content and data. Unsupported
in-use component-model changes should be rejected until a migration is
implemented. See [content configuration](./content-configuration.md) and
[recovery semantics](./operations-and-recovery.md).
diff --git
a/versioned_docs/version-3.1.0/management-packs/content-configuration.md
b/versioned_docs/version-3.1.0/management-packs/content-configuration.md
new file mode 100644
index 0000000..748c540
--- /dev/null
+++ b/versioned_docs/version-3.1.0/management-packs/content-configuration.md
@@ -0,0 +1,111 @@
+---
+title: Edit Complete Configuration Files
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# Edit Complete Configuration Files {#edit-complete-configuration-files}
+
+The reference service packs prefer complete native documents in `content`
properties. This makes it possible to retain application options, comments, and
new upstream settings without waiting for a separate form field for every
setting. Read the [preview scope](./overview.md) before applying this workflow
to an older installation.
+
+## Configuration Files And Basic Settings {#files-and-basic-settings}
+
+Open the service's **Configs** page. **Configuration Files** is the default
view for these packs. **Basic Settings** retains installation inputs,
management identities, listener settings, credentials, and management-operation
parameters. An empty Advanced tab is not shown merely to provide another tab.
+
+| Service | Documents exposed by the reference pack |
+| --- | --- |
+| PostgreSQL | `postgresql.conf`, `pg_hba.conf`, `pg_ident.conf` |
+| Nginx | `nginx.conf` |
+| Kyuubi | `kyuubi-defaults.conf`, environment assignments,
`log4j2.properties` |
+| Trino | `config.properties`, `node.properties`, `log.properties`,
`jvm.config`, catalog documents |
+| Doris | `fe.conf` and `be.conf` |
+| Elasticsearch | `elasticsearch.yml`, JVM options, `log4j2.properties` |
+| MinIO | `minio.env` assignments |
+| Airflow | `airflow.cfg` and `webserver_config.py` |
+| Celeborn | `celeborn-defaults.conf`, environment assignments,
`log4j2.properties` |
+| DolphinScheduler | Role-specific `application.properties`,
`common.properties`, Logback and JVM documents |
+
+
+
+The current content control is a multiline text editor. A dedicated IDE-style
file tree, syntax-aware editor, or universal application validator is not
implied by the presence of complete documents.
+
+## Safe Editing Workflow {#editing-workflow}
+
+1. Select the intended service, configuration group, and current version.
+2. Review **Basic Settings** and any managed paths/listeners before editing
content.
+3. Edit the complete document, retaining required includes and template
placeholders.
+4. Save a configuration version with a useful note.
+5. Apply the required restart, or a supported reload command.
+6. Check the task outcome and the application's effective configuration.
+7. Reopen the configuration version to confirm that the saved document is the
expected one.
+
+Saving an Ambari version and activating a process configuration are separate
operations. A restart-required indicator is not a failed save, and a successful
save alone does not prove the process loaded the file.
+
+## Managed Values And Native Formats {#managed-values-and-formats}
+
+Application settings can coexist with management-controlled identity,
listener, and path values. The pack can add those managed defaults separately.
Conflicting user declarations fail validation rather than silently replacing
the management contract.
+
+Properties files retain comments, continuation lines, escapes, and application
expressions. INI and YAML use their native structure. Environment documents
accept literal `NAME=value` or `export NAME=value` assignments; they do not
execute arbitrary shell programs.
+
+The React saver and Blueprint content handling preserve trailing spaces and
blank lines. A renderer adds a final newline when needed. Do not assume that
arbitrary shell commands, unimplemented service modes, or topology changes
become supported just because their text can be entered.
+
+## Existing Installations And Definition Updates {#existing-installations}
+
+For a supported scalar-to-content transition, Configs prepares a document from
the currently saved values and declared file-format metadata. It remains a
pending edit until saved. Existing saved content is not regenerated from
package defaults, and historical versions remain intact.
+
+Automatic conversion is skipped for scalar configuration-group overrides and
password-typed properties. Those cases retain the legacy runtime representation
until defaults and groups are deliberately converted together. A full-file
group override replaces a document; it does not inherit individual lines as
scalar property overrides did.
+
+Older PostgreSQL and Nginx definitions did not necessarily store the host's
complete configuration files in Ambari. Their new content values are
installation templates, not automatic discovery of customized host files. Seed
the editor from the actual files before applying content management to such an
instance. If the new content types are absent, the legacy runtime path remains
available.
+
+## Nginx Example {#nginx-example}
+
+Within an existing server block, a small verification location can be added:
+
+~~~nginx
+location /docs-check {
+ return 200 "managed configuration\n";
+}
+~~~
+
+Keep the rest of the full document, including the management health include
under `conf.d`. Save the version and execute the declared component `RELOAD`
command where available. The pack validates the candidate using `nginx -t`
before replacing its main file. Reload verification checks the health response
and the exact configuration digest served by the new workers.
+
+If validation fails, inspect the task error and correct the candidate. Do not
repeatedly restart the service with the same invalid file.
+
+## PostgreSQL Example {#postgresql-example}
+
+Change an existing setting within the complete document:
+
+~~~properties
+work_mem = '8MB'
+~~~
+
+After saving and applying the required restart, verify it through a native
query:
+
+~~~sql
+SHOW work_mem;
+~~~
+
+Preserve the supplied path/port placeholders and local peer-management access.
Editing a data-directory placeholder does not migrate database data. The pack
uses `postgres -C`-style native configuration inspection through its server
executable and checks the loaded paths, port, and native error views during
activation.
+
+## Validation Failure And Recovery {#validation-and-recovery}
+
+Nginx and PostgreSQL validate candidates before replacement and keep preceding
file bytes for recovery. Their staging layout includes untouched resources so
relative includes can resolve. Each file replacement is atomic, but a set of
files is not a crash-atomic database transaction.
+
+Activation failure can restore the previous files; PostgreSQL stops a failed
activation before restoration. An external concurrent edit produces an explicit
reconciliation failure. Inspect the task and the retained `.ambari-before`
files before attempting manual recovery.
+
+A configuration rollback does not roll back application data or database
migrations. Separate data backup and migration procedures remain necessary. See
[operations and recovery](./operations-and-recovery.md) for the distinction
between package operations and service tasks.
diff --git
a/versioned_docs/version-3.1.0/management-packs/operations-and-recovery.md
b/versioned_docs/version-3.1.0/management-packs/operations-and-recovery.md
new file mode 100644
index 0000000..3656c17
--- /dev/null
+++ b/versioned_docs/version-3.1.0/management-packs/operations-and-recovery.md
@@ -0,0 +1,128 @@
+---
+title: Mpack Operations And Recovery
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# Mpack Operations And Recovery {#mpack-operations-recovery}
+
+Use the package **Activity** page to follow definition changes, and Ambari's
normal request/task views to follow host installation and service operations.
These records have different identities and completion conditions.
+
+The guidance below applies to the [runtime preview](./overview.md), not to
manually editing Server resource directories or database rows.
+
+## Interpret Operation Phases {#operation-phases}
+
+| Phase | Meaning and next step |
+| --- | --- |
+| `ACCEPTED` | The durable submission exists; wait for processing |
+| `PREPARING` | Candidate resources and prerequisites are being prepared |
+| `WAITING_MAINTENANCE` | Inspect affected scope, blockers, and the required
maintenance action |
+| `WAITING_RESTART` | A real Server restart is required; follow the
operation's restart procedure |
+| `PUBLISHING` | The verified definition view is being published |
+| `SUCCEEDED` | Verify the operation identity and effective result before
using a deployment handoff |
+| `FAILED` | Inspect the exact error and receipts; determine whether a new
plan or eligible retry is appropriate |
+| `RECOVERY_REQUIRED` | Outcome is unresolved; reconcile existing receipts
before deciding what to do |
+| `CANCELLING` | Cancellation is being reconciled; it is not complete yet |
+| `CANCELLED` | Cancellation completed under the Server's validated policy |
+
+An HTTP 202 means accepted, not completed. Do not turn a timeout, missing
response, log message, or unknown state into assumed success.
+
+## Preserve Identity After A Disconnect {#preserve-identity}
+
+Retain the exact `plan_id`, `plan_digest` and idempotency key before
submitting. Once available, retain `operation_id` and `generation` as well. The
browser keeps a pending submission checkpoint under the current account and
offers reconciliation when acceptance is uncertain.
+
+Replaying the same user/plan/key returns the original operation. Creating
another key or plan after a lost response may create different work; first
resolve the original acceptance. A definitively rejected stale plan can be
previewed again.
+
+Shared operation history and another account's local checkpoint are different
things. Do not copy a different user's browser checkpoint or credentials to
force recovery.
+
+## Inspect Through The CLI {#inspect-cli}
+
+Use the matching CLI described in [authoring and
bundling](./authoring-and-bundling.md#cli-import). Substitute the actual
recorded operation ID:
+
+~~~shell
+ambari-mpack --json operations list
+ambari-mpack --json operations show "$OPERATION_ID"
+ambari-mpack --json operations members "$OPERATION_ID"
+~~~
+
+Inspect the phase, error code, affected scope, member identities, and hook
receipts. Diagnostic messages explain problems, but automation must use the
structured fields and exact identifiers.
+
+## Reconcile, Retry, And Cancel {#recovery-actions}
+
+**Reconcile** asks the Server to establish what already happened. It does not
blindly execute a hook again:
+
+~~~shell
+ambari-mpack --json operations recover "$OPERATION_ID"
+~~~
+
+**Retry** is for eligible failed hooks with an authoritative no-effect
observation and supported idempotent behavior:
+
+~~~shell
+ambari-mpack --json operations retry "$OPERATION_ID"
+~~~
+
+**Cancel** is subject to the retained effects and current operation state:
+
+~~~shell
+ambari-mpack --json operations cancel "$OPERATION_ID"
+~~~
+
+Choose the action appropriate to the observed state; these commands are
alternatives, not a recovery script to run in sequence. Applied or uncertain
effects can prevent cancellation or retry. Completed effects are not replayed.
An interrupted cancellation resumes cancellation rather than restarting the
original install/update.
+
+## Scoped Maintenance And Concurrency {#scoped-maintenance}
+
+Long preparation, verification, and hook subprocess work is outside the
exclusive publication lock. A coordinator protects the final view switch and
persistence. Reservations block affected definition consumers and relevant
service/configuration/topology mutations.
+
+Unrelated ordinary writes and tasks can continue. This does not mean all
package publications run concurrently or that two conflicting changes can
operate on the same definition. A shared Stack/version can affect multiple
clusters.
+
+Blocking tasks are identified by their cluster, request, task, and
authoritative status. Existing tasks retain their compatible resource
references. Active Stack upgrades or unsupported in-use component-model changes
can reject the plan. Restarting Server is not a replacement for an
unimplemented component migration.
+
+## Definitions, Software, Configuration, And Data {#different-change-types}
+
+| Change | What it changes | Separate work that may still be needed |
+| --- | --- | --- |
+| Import a newer bundle | Register additional definition releases | Explicitly
select/activate a version |
+| Update an active definition | Scripts, metadata and managed resource
bindings | Host software upgrade or component migration |
+| Save configuration content | Create an Ambari configuration version |
Reload/restart and native verification |
+| Retire/uninstall a definition | Remove eligible definition
ownership/availability | Explicit service retirement and data policy |
+| Restore application data | Service-specific data state | A validated
backup/restore procedure |
+
+Removal may fail because a package, binding, operation, service, or cluster
still uses the resources. Old release records can remain for provenance. Do not
delete Server directories or rows to bypass a reference check.
+
+The reference packs preserve persistent user data on stop and definition
retirement. This is not a universal rollback engine. PostgreSQL's declared
backup/restore operations have their own isolated-target and observation rules;
do not generalize them to every service.
+
+## Troubleshooting By Symptom {#troubleshooting}
+
+| Symptom | Inspect first | Recovery direction |
+| --- | --- | --- |
+| No Management Packs entry | Current account and administrator authorization
| Use an authorized account; a URL does not bypass Server permissions |
+| Import succeeds but no application appears on hosts | Service selection and
deployment handoff | Continue through the new-cluster or Add Services wizard |
+| Service is unavailable | Catalog reason and compatible Stack context |
Correct dependencies/target definitions and refresh the catalog |
+| Several services cannot be selected together | Exact Stack contexts and
destination | Deploy compatible groups separately |
+| Submission response was lost | Saved plan/key and operation record |
Reconcile the existing submission |
+| Plan rejected as `STALE_PLAN` | Catalog revision and changed prerequisites |
Create a fresh preview after definite rejection |
+| `RESOURCE_IN_USE` on removal | Resource usage references | Resolve actual
uses through supported lifecycle actions |
+| `WAITING_RESTART` persists | Real Server restart and subsequent operation
observation | Complete the documented restart/reconciliation step |
+| Package succeeds but installation fails | Host request/task and native
observations | Repair host prerequisites or configuration; do not re-import
blindly |
+| All graphs show no data | Time range, refresh state, datasource and fresh
target observations | Follow the [monitoring
guide](../monitoring/queries-and-dashboards.md#workspace-interactions) |
+
+## Evidence To Include In A Report {#report-evidence}
+
+Include the Server/Agent build, package name/version/digest, exact plan and
operation identities, affected clusters, observed phase/error code, relevant
task IDs, software observations, and recovery actions already attempted. For
configuration failures, include a redacted diff and configuration-version
identity.
+
+Keep passwords, tokens, cookies, database connection secrets and private keys
out of reports and screenshots. A package success record, a service task
result, and a monitoring query result should each be identified separately.
diff --git a/versioned_docs/version-3.1.0/management-packs/overview.md
b/versioned_docs/version-3.1.0/management-packs/overview.md
new file mode 100644
index 0000000..001c051
--- /dev/null
+++ b/versioned_docs/version-3.1.0/management-packs/overview.md
@@ -0,0 +1,86 @@
+---
+title: Mpack Store Overview
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# Mpack Store Overview {#mpack-store-overview}
+
+The mpack store is a separately maintained collection of Ambari service
definitions and lifecycle scripts. A distributor can package the selected
releases into one `mpackstore.bundle.tar.gz`. An administrator imports that
bundle once, then chooses the services to manage through Ambari's normal
deployment wizard.
+
+:::info Development snapshot
+These guides describe the `AMBARI-26663` development implementation reviewed
on 2026-09-29, including Ambari commit `3a71190847` and reference-store commit
`c10a271`. They require a build containing that implementation. The 3.1
documentation remains a preview; these snapshots do not establish an ASF
release or production support matrix. See the [source
baseline](../release-baseline.md#runtime-mpack-follow-up).
+:::
+
+## What The Store Contains {#store-contents}
+
+A full store bundle transports individually versioned packages, manifests,
service descriptors, configuration definitions, and installation/management
scripts. The reference snapshot contains eleven packages: one foundation
package and ten selectable services.
+
+Host software comes from the repositories, verified binary archives, Python
dependencies, or pinned source builds described by each pack. Importing the
store does not fetch all of those runtime artifacts onto every host. Prepare
them before installation, especially for a disconnected environment.
+
+| Object | Purpose | Example |
+| --- | --- | --- |
+| Bundle | Transport several independent packages together |
`mpackstore.bundle.tar.gz` |
+| Package release | Identify an immutable management definition |
`nginx/1.0.1.1` |
+| Stack context | Define the environment to which services can be bound |
`GENERIC/1.0` or `BIGTOP/3.3.0` |
+| Catalog service ID | Select one exact provider/context in a deployment plan
| The ID returned by the service catalog |
+| Service descriptor version | Supply the version label from service metadata
| The version in `metainfo.xml` |
+| Software version | Identify the application installed on a host | Trino
`483` |
+| Operation | Track a durable package change and its recovery | An operation
ID and authoritative phase |
+
+The version beside a service name comes from descriptor metadata; it must not
replace an observed installed-software version. For example, a Kyuubi
descriptor can say `1.0` while the reference runtime is `1.9.4`. The package
version in the selector identifies the management definition. Updating scripts
in a package does not by itself upgrade the application binary or its database
schema.
+
+## The End-to-End Flow {#end-to-end-flow}
+
+| Stage | Result to verify |
+| --- | --- |
+| Obtain and inspect | The bundle matches the expected publisher, versions,
and digest |
+| Upload and import | Package releases appear in the catalog; host software
has not been deployed |
+| Select services and destination | One provider per chosen service, with a
compatible environment |
+| Enable definitions | The package operation reaches a verified successful
state |
+| Deploy through the wizard | Host assignments and configuration produce
successful installation/start tasks |
+| Run service checks | The service responds correctly; the check's result
belongs to the actual request |
+| Operate | Edit configurations, inspect alerts, and use declared lifecycle
commands |
+
+Importing a multi-service bundle does not select every service. The Server
resolves required package dependencies and bindings for the chosen services;
deployment prerequisites still need operator input.
+
+For a new cluster, the handoff opens cluster creation. For a compatible
existing cluster, it opens Add Services with the selected services. A
successful definition operation is not proof that the subsequent installation
has completed.
+
+## Administration And Scope {#administration-and-scope}
+
+The Management Packs entry is an Ambari administrator function. The runtime
endpoints require authenticated administrator access and
`AMBARI.MANAGE_STACK_VERSIONS`. Service deployment and later lifecycle actions
also retain their normal permissions and validation.
+
+The store is global to an Ambari Server. Definition bindings are shared by
exact Stack name and version, rather than providing independent definition
versions for each cluster. A definition update may therefore affect several
clusters using the same context. Review the plan's affected clusters and
maintenance requirements.
+
+Package operations reserve their affected definition scope. Ordinary writes
and tasks unrelated to that scope can continue. This does not permit a
conflicting service, configuration, or topology change while its definitions
are being replaced. See [operation recovery](./operations-and-recovery.md).
+
+## Choosing A Reading Path {#reading-paths}
+
+- Operators: start with the [store walkthrough](./store-guide.md), then
inspect [service prerequisites](./service-catalog.md).
+- Administrators changing configurations: use the [content configuration
guide](./content-configuration.md).
+- Pack maintainers: use [authoring and bundling](./authoring-and-bundling.md).
+- Operators handling failed or interrupted work: use [operations and
recovery](./operations-and-recovery.md).
+- Web users: read [workspace navigation and
appearance](../frontend/workspace-and-appearance.md) and [monitoring
interactions](../monitoring/queries-and-dashboards.md#workspace-interactions).
+
+## Current Boundaries {#current-boundaries}
+
+The reference acceptance environment is Rocky Linux 8 on aarch64 with systemd.
Individual services have different Java, Python, database, repository, and
network requirements. Existing definitions for another platform do not
establish tested deployment support there.
+
+The first service packs focus on basic installation, configuration,
start/stop, and service checks. HA, automatic failover, topology expansion,
software upgrades, schema migrations, and production security vary by service
and must not be assumed. Installing a service also does not automatically add
its exporter or dashboards.
+
+The runtime store workflow and the legacy `ambari-server install-mpack`
mechanism have different manifests and activation behavior. Use the
[management-pack compatibility
entry](../ambari-design/stack-and-services/management-packs.md) before mixing
older instructions with this preview.
diff --git a/versioned_docs/version-3.1.0/management-packs/service-catalog.md
b/versioned_docs/version-3.1.0/management-packs/service-catalog.md
new file mode 100644
index 0000000..e8e1996
--- /dev/null
+++ b/versioned_docs/version-3.1.0/management-packs/service-catalog.md
@@ -0,0 +1,89 @@
+---
+title: Reference Service Catalog
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# Reference Service Catalog {#reference-service-catalog}
+
+This matrix describes the separate reference store at `c10a271` for the
[runtime mpack preview](./overview.md). The package versions come from
`release.json`. They are definition versions, independent of the upstream
software and of Ambari's own version.
+
+## Packages And Software {#packages-and-software}
+
+| Package | Definition version | Software baseline | Environment |
+| --- | --- | --- | --- |
+| generic-base | `1.0.0.3` | Foundation definitions, no application |
`GENERIC/1.0` |
+| nginx | `1.0.1.1` | OS repository package | `GENERIC/1.0` |
+| postgresql | `1.0.1.1` | OS repository package; reference deployment uses
PostgreSQL 10 | `GENERIC/1.0` |
+| kyuubi | `1.0.1.0` | Apache Kyuubi 1.9.4 | `BIGTOP/3.3.0` |
+| airflow | `1.0.1.0` | Apache Airflow 3.3.2 | `GENERIC/1.0` |
+| celeborn | `1.0.1.0` | Apache Celeborn 0.7.0 | `BIGTOP/3.3.0` |
+| dolphinscheduler | `1.0.1.0` | Apache DolphinScheduler 3.1.9 |
`BIGTOP/3.3.0` |
+| trino | `1.0.1.0` | Trino 483 | `BIGTOP/3.3.0` |
+| doris | `1.0.1.0` | Apache Doris 4.1.4 | `BIGTOP/3.3.0` |
+| elasticsearch | `1.0.1.0` | Elasticsearch 9.5.4 | `GENERIC/1.0` |
+| minio | `1.0.1.0` | MinIO `RELEASE.2025-10-15T17-29-55Z` | `GENERIC/1.0` |
+
+The foundation is pulled in as a package dependency; it is not an extra
application to deploy. Nginx and PostgreSQL do not require a Hadoop
installation. A generic service and a BIGTOP service cannot be combined into an
arbitrary single environment just because both are in the bundle.
+
+## Topology And Prerequisites {#topology-and-prerequisites}
+
+| Service | Initial topology | Prepare before installation |
+| --- | --- | --- |
+| Nginx | A managed server instance | OS packages, configuration/include
paths, and a free managed listener |
+| PostgreSQL | A managed database instance | OS packages, persistent data
directory, local management access, and backups |
+| Kyuubi | Server and client definitions | JDK 17, compatible Spark 3.5/Scala
2.12 binaries, Hadoop clients and ZooKeeper configuration |
+| Airflow | One server host using LocalExecutor | Python 3.11 and an external
PostgreSQL 14-18 database, database user and administrator inputs |
+| Celeborn | One master and one or more workers | JDK 17, pinned official
archive, storage paths and role ports |
+| DolphinScheduler | One host supervising master, worker, API and alert
processes | External PostgreSQL 14-18, ZooKeeper, Java 11 or 17, and
administrator inputs |
+| Trino | One coordinator, optional workers | Java 25 on every assigned host,
pinned archive, node/data paths and ports |
+| Doris | Exactly one FE and one BE, together or separate | ARM64 archive,
Java 17, data directories, sufficient temporary/extracted disk space and
explicit credentials |
+| Elasticsearch | One authenticated HTTPS node | Official Linux/ARM64 archive,
kernel/OS prerequisites, data directory and protected administrator input |
+| MinIO | One source-built server and console | Pinned source, Go toolchain
1.24.8, module access/cache, persistent storage and new root credentials |
+
+The PostgreSQL 10 reference service does not satisfy the Airflow or
DolphinScheduler PostgreSQL 14-18 requirement. Prepare a suitable external
database rather than assuming that installing the PostgreSQL card completes
those prerequisites.
+
+Doris's recorded archive is about 4.35 GB and expands to about 6.8 GB before
service data. Check free space for download, extraction, previous
installations, metadata, and application data; the store bundle's size is not a
sizing estimate.
+
+## Service-specific Initialization {#service-initialization}
+
+**Airflow:** installation creates an isolated Python environment, initializes
only an empty dedicated database, and verifies administrator provisioning.
Existing schemas are checked rather than automatically upgraded. The declared
`INITIALIZE_DATABASE` and `CREATE_ADMIN` actions remain available for explicit
recovery. Verify the dedicated health workflow. The first pack fixes
LocalExecutor; selecting another executor in a file does not provide Celery
workers or a broker deployment.
+
+**DolphinScheduler:** the managed pseudo-cluster uses an external persistent
PostgreSQL schema and ZooKeeper. It does not use the upstream standalone
in-memory H2/testing-ZooKeeper path. Empty-schema ownership, initialization,
and administrator setup are part of the managed lifecycle. Do not reuse a
nonempty foreign schema as an initialization target.
+
+**Kyuubi:** the pack pins the official binary and can wrap it into a
compatible RPM using the provided packaging tool. It does not build Kyuubi from
source during the normal binary packaging path. Configure matching Spark/Hadoop
dependencies before starting engines.
+
+**Trino:** Java 25 is a service-specific prerequisite even though Ambari's own
Java baseline is 17. The supplied TPCH catalog is for verification. Hive,
Iceberg, authentication, TLS and production resource groups need explicit
configuration and validation.
+
+**MinIO:** the current reference is installable from its pinned source build;
the earlier non-installable draft is superseded. The build verifies source and
reproduced binary digests. The management definition does not redistribute the
MinIO binary inside the store; inspect the upstream AGPL-3.0 licensing and
source distribution requirements for your distribution.
+
+## What Service Checks Establish {#service-checks}
+
+Checks use service-native observations. Representative examples include a
verified Kyuubi engine/session operation, an Airflow health DAG result,
registered Celeborn workers, authenticated DolphinScheduler processes, a Trino
TPCH query, a Doris temporary table write/read, Elasticsearch authenticated
cluster checks, and a MinIO object write/read/cleanup.
+
+Temporary test resources belong to the specific execution. A process existing,
a successful download, or a command exiting zero is not sufficient evidence for
every check. Inspect the Ambari request/task result and the service's
structured observations.
+
+A passed basic check does not prove HA, security hardening, backup
restoration, production capacity, or arbitrary connector compatibility.
+
+## Limits And Extension Work {#limits-and-extension-work}
+
+The reference first releases do not promise HA or automatic failover. Airflow
CeleryExecutor, distributed MinIO storage, Celeborn HA, Doris replication/cloud
mode, automatic schema upgrades, and production connector integration require
separate implementation and acceptance.
+
+Stopping a service or retiring its definition is not a request to delete
persistent user data. Removal can still be blocked by active uses. Review
[operation semantics](./operations-and-recovery.md) before changing bindings.
+
+All ten service packs expose [editable configuration
documents](./content-configuration.md). Dedicated service telemetry remains a
separate capability; Linux host metrics alone do not establish service-level
monitoring coverage.
diff --git a/versioned_docs/version-3.1.0/management-packs/store-guide.md
b/versioned_docs/version-3.1.0/management-packs/store-guide.md
new file mode 100644
index 0000000..2d76d1e
--- /dev/null
+++ b/versioned_docs/version-3.1.0/management-packs/store-guide.md
@@ -0,0 +1,90 @@
+---
+title: Import A Store And Deploy Services
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# Import A Store And Deploy Services {#import-store-deploy-services}
+
+This walkthrough uses the [runtime mpack preview](./overview.md). Obtain the
reviewed bundle from the distributor of your matching development build, or
[build it from the reference repository](./authoring-and-bundling.md).
+
+## Before You Start {#before-you-start}
+
+Have an administrator account, an enabled runtime mpack API, compatible
Server/Agent builds, and a bundle whose digest you can verify. Prepare
reachable software sources, required databases, Java/Python runtimes, writable
data directories, and available ports for the services you intend to select.
Read the [service matrix](./service-catalog.md) before assigning hosts.
+
+Record the current package versions, affected cluster configurations, and data
backup arrangements before replacing active definitions. A definition archive
is not a data backup.
+
+## Open Management Packs {#open-management-packs}
+
+From a cluster workspace, use **Management Packs** near the top of the
sidebar, below the Ambari brand and global Clusters entry. From a global
directory, use **Management Packs** in the top navigation.
+
+The page has **Service catalog**, **Imported packages**, and **Activity**
sections. The right-hand selection panel stays with the catalog as you browse.
**Return to workspace** restores the cluster page you left, including its URL
parameters.
+
+
+
+This development capture uses the Chinese UI and dark appearance. Host names,
counts, and displayed versions describe the captured test environment.
+
+## Import The Bundle {#import-the-bundle}
+
+1. Select **Import bundle** to open the upload dialog.
+2. Choose `mpackstore.bundle.tar.gz`. Wait for inspection to identify its
member packages.
+3. Review the members, then select **Import Packages**. The complete-store
import includes all inspected members.
+4. Follow the operation in **Activity**. Keep its operation ID if the browser
or network disconnects.
+5. Return to **Service catalog** after the import succeeds.
+
+Import registers the packages without binding their definitions, running
activation hooks, or deploying software on hosts. The default upload contract
limits the compressed archive to 256 MiB, expanded contents to 1 GiB, and
entries to 100,000; confirm the limits of the actual Server build.
+
+Do not place multi-gigabyte runtime distributions inside the store merely to
make installation offline. Use the runtime repository/cache preparation
described by each service.
+
+## Select One Version Per Service {#select-one-version}
+
+Search by service or package and narrow the environment selector when useful.
The catalog groups entries by service and exact Stack context; versions for
that group appear in one selector instead of duplicate cards.
+
+The default prefers a currently enabled definition. Other numeric definition
versions are ordered by version, but a newer number is not a certification of
compatibility or runtime upgrade support. Review the package's release
information before switching.
+
+Check the service to add it to **Selected services**. Changing its version
replaces that group's selected provider. The selection panel shows the actual
package release, not just the software name. Remove an unwanted service there.
+
+Services incompatible with the current selection or chosen destination are
disabled with an explanation. Clear or change the selection to choose a
different environment. Filtering the catalog does not silently remove already
selected services.
+
+## Choose A Destination {#choose-a-destination}
+
+Select **New cluster** or an existing compatible cluster in **Deploy To**,
then use **Continue With Selected Services**.
+
+The Server derives required providers and bindings. A plan may require
maintenance or restart confirmation; inspect its affected clusters and
requirements. A straightforward enable operation can proceed without an extra
confirmation dialog. Both paths still produce a durable operation.
+
+**Definitions enabled** describes management-definition availability. It does
not mean that the service is already installed and running on a host.
+
+## Complete The Deployment {#complete-the-deployment}
+
+After a verified successful enable operation, use the offered **Create
cluster** or **Add Services to Cluster** action. In the wizard:
+
+1. Confirm the selected services and dependencies.
+2. Assign components to eligible hosts.
+3. Enter required credentials, database endpoints, software locations, and
configuration.
+4. Review the assignments and start installation.
+5. Inspect install/start tasks and service checks, then open the service
Summary and Configs pages.
+
+Treat an installation task failure separately from a package-operation
failure. The operation ID and the deployment request/task IDs identify
different workflows; retain both when diagnosing a problem.
+
+## Recover Without Duplicating Work {#recover-without-duplicates}
+
+If submission acceptance is uncertain, use the page's reconciliation action.
It reuses the retained plan/submission identity rather than assuming that a
timeout means nothing happened.
+
+If a plan has expired or its inputs changed and acceptance was definitively
rejected, create a fresh preview. If the operation is waiting on tasks or
maintenance, inspect the exact blockers before retrying. Do not repeatedly
upload the same bundle to recover a host installation failure.
+
+See [operations and recovery](./operations-and-recovery.md) for phase
meanings, CLI inspection, and recovery restrictions.
diff --git a/versioned_docs/version-3.1.0/monitoring/queries-and-dashboards.md
b/versioned_docs/version-3.1.0/monitoring/queries-and-dashboards.md
index 03ec798..28daef0 100644
--- a/versioned_docs/version-3.1.0/monitoring/queries-and-dashboards.md
+++ b/versioned_docs/version-3.1.0/monitoring/queries-and-dashboards.md
@@ -85,6 +85,51 @@ The editor supports panel configuration, variables, cloning,
JSON import/export,
Ambari binds the reserved `cluster` variable to the current application
cluster and computes `__rate_interval` as the larger of four query steps or 120
seconds. These reserved variables are not user-editable dashboard filters.
Counters use `rate` or `increase`; gauges are queried directly.
+## Workspace Interactions {#workspace-interactions}
+
+The following interactions describe the [runtime mpack/console development
follow-up](../management-packs/overview.md). Confirm that your installed Web
build includes it; the older pinned monitoring evidence above does not by
itself establish these newer controls.
+
+### Refresh And Time Range {#refresh-and-time-range}
+
+Relative-time dashboards default to a 30-second refresh interval. The
preference is stored per user and cluster, including an explicit pause. A
paused view offers **Resume live updates**. Absolute historical ranges and
layout editing do not automatically advance.
+
+Queries preserve seconds rather than rounding the end time down to the minute.
Time-series axes use the selected query boundaries, including when only one
sample is available. After installing collection, allow initial samples to
arrive; rate-based CPU or throughput queries need enough observations to
calculate a rate.
+
+### Read And Control The Legend {#legend-controls}
+
+A disk-throughput legend entry represents a host, device, and read/write
direction. It does not represent every metric from that host.
+
+| Action | Effect |
+| --- | --- |
+| Click a series name | Toggle only that curve's visibility |
+| Select **Only** | Display only the chosen curve |
+| Select **Show all** | Restore all returned curves |
+| Scroll the legend | Browse the remaining entries without shrinking the plot
to fit every label |
+
+
+
+Hidden entries have a crossed-out label and hidden-state icon. The counter
shows displayed versus returned series; an all-hidden state has an explicit
message. Colors and visibility follow the metric labels and query-target
identity across refresh or reordering. In an isolated view, newly arriving
series remain hidden. If the selected series leaves the result, use **Show
all** to inspect the others.
+
+These controls affect presentation only. Collection and storage continue.
Starting a different query resets that chart's visibility context.
+
+### Move From A Chart To Explorer {#chart-to-explorer}
+
+Open the panel menu and choose **View query**. Explorer receives the resolved
query, datasource, cluster route, and time range. Review them and run the query
explicitly.
+
+Explorer distinguishes not-yet-run, loading, successful results, no matching
series, and query failure. Cancel stops the in-flight request, and a late
response from a superseded context must not replace the current result. Editing
inputs marks existing results as belonging to the previous query until another
query completes.
+
+Use the chart/data view controls to inspect results. Recent query history is
scoped by user and persistent cluster identity. A browser storage failure does
not prevent querying. Keyboard users can run with Ctrl/Command + Enter.
+
+### Inspect Targets And Datasources {#inspect-targets-and-datasources}
+
+Targets supports filtering by host, component or endpoint, a needs-attention
filter, and a detail drawer. From a target's details, **View query** carries
its exact labels into Explorer.
+
+For the managed VictoriaMetrics datasource, the view combines Ambari service
discovery with stored scrape success, sample timestamp, and duration
observations. It does not ask the storage node to report a separate VMAGENT's
targets. Missing, conflicting, foreign, or older-than-five-minute observations
are not shown as healthy; without a reliable recent observation, the state is
unknown. An explicit failed scrape differs from an unknown state.
+
+Other datasources retain their native target-metadata behavior. An unsupported
metadata endpoint produces an explicit capability message; it must not be
treated as an empty successful catalog.
+
+Datasource details show scope, endpoint and whether authentication is
configured. **Enabled** is a configuration setting, not a connectivity-test
result. Check the query path, discovery/collection, and service-specific metric
coverage separately.
+
## API Examples {#api-examples}
The query endpoint below is relative to Ambari's normal `/api/v1` base. Use a
datasource ID from the datasource list, not a dashboard ID. Keep the query
URL-encoded:
diff --git a/versioned_docs/version-3.1.0/release-baseline.md
b/versioned_docs/version-3.1.0/release-baseline.md
index 1cbf306..10bc1f4 100644
--- a/versioned_docs/version-3.1.0/release-baseline.md
+++ b/versioned_docs/version-3.1.0/release-baseline.md
@@ -73,6 +73,25 @@ The [multi-cluster guides](./multi-cluster/architecture.md)
use the newer pinned
The guides distinguish final packaged independent-cluster evidence from the
earlier managed-HBase deployment with overlays. They also document the
remaining real-KDC, detach/data-retention, fault-injection and
broker-revocation gates. The [operations
guide](./multi-cluster/operations.md#upgrade-and-acceptance-work) lists the
evidence still needed before publishing final support claims.
+## Runtime Mpack And Console Follow-up {#runtime-mpack-follow-up}
+
+The runtime-store guides add a separately identified development follow-up
reviewed on 2026-09-29:
+
+| Input | Reviewed snapshot |
+| --- | --- |
+| Ambari implementation | Branch `AMBARI-26663`, commit
`3a71190847503b033036833d1d49ba0ce325ca41` |
+| Independent reference store | Commit `c10a271`; exact definition versions
selected by `release.json` |
+| Reference deployment scope | Rocky Linux 8/aarch64, systemd, basic non-HA
services |
+| Console acceptance scope | Desktop; grouped service selection, content
editors, appearance/navigation and monitoring interactions |
+
+The implementation snapshots were reviewed in development checkouts. They are
not presented as newly published Apache source tags, downloadable ASF binary
releases, or proof that every 3.1 build contains these changes. Obtain a build
and store supplied together, and inspect the published manifest/API
capabilities before using the workflow.
+
+Evidence inputs include the core checkout's `docs/mpack/http-api.md`,
`docs/mpack/corrective-implementation.md` and
`docs/frontend-refactor/react-current`, plus the store's `release.json`,
service READMEs, `docs/content-configuration.md` and
`docs/content-configuration-acceptance.md`. The later content-configuration
acceptance supersedes earlier definition-version examples and the old
non-installable MinIO draft.
+
+The snapshot has basic runtime checks for the ten selected services and
targeted configuration failure/recovery checks. It does not establish general
HA, multi-platform, all-role, data-migration, or production-load certification.
Website build/browser tests establish documentation behavior only.
+
+Start with the [store overview](./management-packs/overview.md), [service
matrix](./management-packs/service-catalog.md), and [workspace
guide](./frontend/workspace-and-appearance.md).
+
## Before Publishing A Release {#before-publishing-a-release}
Update this baseline after the release candidate is selected. Record final
source tags, signed artifact/checksum locations, package target matrix,
supported upgrade paths, test results, and the release vote outcome. Only then
replace the preview designation with the released version.
diff --git a/versioned_docs/version-3.1.0/release-notes.md
b/versioned_docs/version-3.1.0/release-notes.md
index 118e003..bff24ff 100644
--- a/versioned_docs/version-3.1.0/release-notes.md
+++ b/versioned_docs/version-3.1.0/release-notes.md
@@ -77,6 +77,14 @@ Monitoring is packaged separately for the VictoriaMetrics
provider. The retained
See [RPM packaging](./platform/rpm-packaging.md) for build commands and
artifact inspection, and [building from
source](./ambari-dev/building-from-source.md) for the complete build
environment.
+## Runtime Store And Console Preview {#runtime-store-and-console-preview}
+
+A separately documented AMBARI-26663 development follow-up adds complete-store
import, per-service/provider selection, scoped definition maintenance, complete
configuration documents, and recoverable package operations. Importing a bundle
registers definitions; the normal wizard still performs installation.
+
+The main console also adds light/dark/system appearance, prominent global
navigation with return to the previous cluster page, grouped package versions,
compact host alert links, and explicit monitoring legend controls. These
features require the [matching development
snapshot](./release-baseline.md#runtime-mpack-follow-up).
+
+See [Management Pack Store](./management-packs/overview.md), [Complete
Configuration Files](./management-packs/content-configuration.md), and
[Workspace Navigation and Appearance](./frontend/workspace-and-appearance.md)
for procedures and limits. This entry does not announce a hosted marketplace,
an ASF binary store release, automatic software upgrades, or HA support for the
reference packs.
+
## Community Improvements {#selected-community-changes}
### Cluster Operations And Configuration {#cluster-operations}
diff --git a/versioned_sidebars/version-3.1.0-sidebars.json
b/versioned_sidebars/version-3.1.0-sidebars.json
index c4d5d92..c188b10 100644
--- a/versioned_sidebars/version-3.1.0-sidebars.json
+++ b/versioned_sidebars/version-3.1.0-sidebars.json
@@ -36,6 +36,19 @@
"multi-cluster/operations"
]
},
+ {
+ "type": "category",
+ "label": "Management Pack Store",
+ "collapsed": false,
+ "items": [
+ "management-packs/overview",
+ "management-packs/store-guide",
+ "management-packs/service-catalog",
+ "management-packs/content-configuration",
+ "management-packs/authoring-and-bundling",
+ "management-packs/operations-and-recovery"
+ ]
+ },
{
"type": "category",
"label": "Monitoring",
@@ -141,6 +154,7 @@
]
},
"frontend/react-ui",
+ "frontend/workspace-and-appearance",
"frontend/customizing-react-ui",
{
"type": "category",
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
