diff --git a/architecture/ayatori-control-plane.md b/architecture/ayatori-control-plane.md index fac8860..f8b6c64 100644 --- a/architecture/ayatori-control-plane.md +++ b/architecture/ayatori-control-plane.md @@ -34,6 +34,11 @@ Agent/CLI 和人工任务。当前 Job controller 是控制循环与 adapter 的 内部 Run 能力，不构成 FaaS、Cloud Run 或应用托管承诺。KaaS 只有出现实际需求时才评估，不是 产品路线的必达终点。 +Compute 方向已被记录但延后实施：选择性复用 `core/v1 Node` 与 Lease，由 Ayatori Compute Agent +实现节点状态并由自有 controller 调度，不引入 kubelet、Pod 或 kube-scheduler。长期 VM 主路径 +可以是普通 Linux 节点上的 libvirt/QEMU；Proxmox 用于 brownfield adopt 和过渡。OpenSandbox/Kata +microVM 属于 Run/Sandbox 的隔离实现，不因此成为 VirtualMachine 资源。 + 详细设计以 Ayatori 仓库的 [ADR-0001](https://git.ddupan.top/panxiao81/ayatori/src/branch/main/docs/decisions/0001-kubernetes-api-machinery.md) 、[ADR-0006](https://git.ddupan.top/panxiao81/ayatori/src/branch/main/docs/decisions/0006-demand-driven-resource-scope.md) diff --git a/architecture/constraints.md b/architecture/constraints.md index 3ee9492..916e31f 100644 --- a/architecture/constraints.md +++ b/architecture/constraints.md @@ -9,6 +9,7 @@ | Ayatori 复用 Kubernetes API machinery，不复用其容器编排产品边界 | kube-apiserver/etcd 提供 API、watch、RBAC 与状态协调；领域调度、生命周期、恢复和 GC 属于 Ayatori controllers；Kubernetes workload 只是可替换 backend | [Ayatori 控制面边界](ayatori-control-plane.md) | | Kubernetes 内置资源不绑定上游实现组件 | 可由 Ayatori Agent/controller 实现和消费 Node、Lease 等 API；使用 Node 不推导必须部署 kubelet、Pod 或 kube-scheduler | [Ayatori 控制面边界](ayatori-control-plane.md) | | Ayatori 只为已验证的管理缺口新增北向资源 | 当前优先 Database、LoadBalancer、Bucket/Object Storage；VM 价值已确认但南向较重；Run 是内部切片，KaaS 按需，FaaS/PaaS 默认不做 | [Ayatori 控制面边界](ayatori-control-plane.md) | +| Ayatori Compute 复用 Node/Lease API，但不引入 Kubernetes workload plane | Compute Agent 实现 Node 状态；libvirt 是长期候选主路径，PVE 是 brownfield 过渡；Kata microVM 属于 Sandbox backend | [Ayatori 控制面边界](ayatori-control-plane.md) | | Samba AD、OCI、Proxmox 优先 IaC，以代码为准 | Ansible/Terraform 声明及任务优先于旧 README；声明不等于已验证部署 | 维护者于 2026-09-16 明确、各服务使用指南 | | 服务独立部署，Terraform root/state 按服务隔离 | 避免认证和变更影响范围绑在一起 | `AGENTS.md`、`CLAUDE.md` | | OpenBao 恢复不能依赖 k3s 或读取自己内部的恢复凭据 | 先恢复信任根，再恢复消费者 | `infrastructure/openbao/README.md`、`CLAUDE.md` | diff --git a/services/postgresql-tenant-operator.md b/services/postgresql-tenant-operator.md index 320aa91..9b886d1 100644 --- a/services/postgresql-tenant-operator.md +++ b/services/postgresql-tenant-operator.md @@ -2,7 +2,7 @@ title: PostgreSQL Tenant Operator（计划中的 DBaaS） lifecycle: planned evidence: documented -last_reviewed: 2026-09-16 +last_reviewed: 2026-09-20 last_verified: null sources: - https://git.ddupan.top/panxiao81/postgresql-tenant-operator @@ -31,6 +31,16 @@ homelab 资源有限，为每个应用维护一套数据库会浪费资源。绝 已批准的设计合同不等于已经实现的功能，本文不表示 DBaaS 已上线。 项目首页还注明 `config/samples` 保留旧 API 骨架，不能将其直接当作最终使用接口。 +2026-09-20，维护者决定将该项目合并为 Ayatori 的 Database 领域模块。已批准的规格、领域模型、 +状态机和测试继续作为迁移合同；不会把独立仓库的 manager、生成文件和当前工作树整仓复制。 +迁移须等待正在进行的 Instance 工作形成可引用 source commit，再按领域层、API、adapter 和 +controller 的纵向切片进入 Ayatori。旧仓库在迁移完成并验收前仍是现有设计与代码的来源， +本决定不表示 DBaaS 已上线。 + +合并边界记录在 Ayatori PR +[#2 的 ADR-0008](https://git.ddupan.top/panxiao81/ayatori/src/branch/feat/kubernetes-job-controller/docs/decisions/0008-merge-postgresql-tenant-operator.md)； +该链接当前指向未合并分支，合并后应改为 main 固定来源。 + ## 计划中的使用方式 1. 平台管理员通过 `PostgreSQLInstance` 注册已有 PostgreSQL 实例及管理连接。 @@ -63,5 +73,6 @@ GitOps、Terraform、kubectl 和未来 Backstage 计划共用这套 Kubernetes A - [部署](https://git.ddupan.top/panxiao81/postgresql-tenant-operator/src/branch/main/docs/deployment.md)与[安全](https://git.ddupan.top/panxiao81/postgresql-tenant-operator/src/branch/main/docs/security.md)：依赖和权限。 - [迁移](https://git.ddupan.top/panxiao81/postgresql-tenant-operator/src/branch/main/docs/migration.md)与[运维](https://git.ddupan.top/panxiao81/postgresql-tenant-operator/src/branch/main/docs/operations.md)：现有数据库、删除和恢复合同。 -具体实现进度回到[项目仓库](https://git.ddupan.top/panxiao81/postgresql-tenant-operator)查询， -后续查询前先向维护者对齐当前工作与 ticket。本页保留设计定位和带日期的阶段摘要。 +迁移前的具体实现进度仍回到[项目仓库](https://git.ddupan.top/panxiao81/postgresql-tenant-operator) +查询；迁移后的实现与发布进度转到 Ayatori。后续查询前先向维护者对齐当前工作与 ticket。 +本页保留设计定位和带日期的阶段摘要。