Heat 模板仓库 (Heater)

Heat 模板仓库 (Heater) 是一个用于存储、管理和版本控制“已知良好”模板的服务。其目标是允许组织编码并轻松共享架构知识，通过模板库实现。设想的功能包括索引、标记和搜索、版本控制、可配置的后端存储以及扩展的元数据组合。

Heater 的主要功能是作为中心化的模板库。它应该可以安装和管理在任何特定的 OpenStack 环境之外，并且与任何一个 Heat 安装没有关联。许多不同的组织应该能够轻松启动 Heater 并定义他们自己关于发布和存储的策略。

用例

作为客户端用户，我希望能够查询包含策划/支持的模板列表的服务，以便利用我的服务提供商在各种应用程序架构方面的专业知识。
目录的用户希望能够通过关键字搜索模板。
服务维护者希望拥有一个可以管理 Heat 模板并维护相关关键字和元数据的仓库。
1. 将关键字与模板关联允许服务提供商对模板进行分类，以便于分组和搜索具有相关主题或功能的模板。
2. 类似于 Nova 和其他 OpenStack 项目，允许使用键/值元数据允许服务提供商关联基本模式未涵盖的上下文关键字。
作为服务提供商，我希望拥有一个中心化的仓库，可以在其中共享编码在 Heat 模板中的机构系统架构知识。
作为服务提供商，我应该控制对该中心化仓库的访问，并确定谁可以创建、删除或修改现有的 Heat 模板。
作为服务提供商，我需要能够使用可搜索、可索引的关键字标记模板。
服务提供商希望能够通过用户角色限制模板的可见性，以便为不同用户角色支持不同的 SLA。

认证/访问控制

通过 Keystone 处理，如常

API

(规范即将发布 - 只是对可能的端点/操作的基本概述)

提交模板和可选的元数据和标签

 POST /templates

 template-type: Application
 keystone-roles:
 - admin
 - demo
 application:
   name: Wordpress
   version: 3.6.1
   flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
   weight: 3
 icons: 
 - href: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-tattoo.png
   type: default
 - href: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
   type: small
 keywords:
 - wordpress
 - mysql
 meta:
   some-junk: junk
   color: sadness
 template:
   <raw template data>
 
 documentation:
   abstract: 
     some abstract...
   guide:
     This blueprint includes a single server running Wordpress with Varnish.
     This blueprint's performance has not been measured.
   instructions:
     If you're new to WordPress, the
     documentation will step you through the process of logging into the
     admin panel, customizing your blog, and changing your theme.

检索模板列表

 GET /templates?limit=100

检索模板的版本（默认发布版本，带/不带元数据）

 GET /templates/:id?meta=horizon&meta=documentation&version=b6059

查看模板版本历史记录

GET /templates/:id/history
{
    current: b6059,
    b6059: {
        version: b6059,
        submitted: ... a date ...
        ref: ... resource uri to the actual version details ....,
    },
    985a4: {
        version: 985a4,
        submitted: ... a date ....
        ref: ...resource uri to the actual version details ....
    }
}

GET /templates/:id/history/:rev
{
    version: ref,
    submitted: .. a date ..
    comment: "A description of the change/difference"
    published: Not present if not published, otherwise the publish date
   
}

将模板版本发布为 LKG（管理员）
拒绝模板版本（管理员）
向现有模板版本添加元数据
将元数据提升到模板的 LKG 版本（管理员）
添加/删除模板的标签

关联元数据

用户应该能够将元数据与模板关联，以促进与 Horizon 等其他工具的集成。此元数据将与原始模板分开保存，以确保模板的可用性不会受到任何给定工具的要求的影响。用户应该始终能够检索不包含关联元数据的模板。但是，此服务应允许用户检索包含模板及其元数据（或其子集）的“包”。元数据的一些示例类型包括

用于在 GUI 中显示模板资源的提示（定位、大小等）
关联图标
文档扩展
替代版本
变更日志

版本控制和发布

Heater 应该支持一个非常简单的（可选的）发布模型，指定用户可以审查模板的修订以及元数据，并将其发布为模板的“官方”或 Last Known Good (LKG) 版本。期望这种发布模型保持非常简单，避免复杂的审查工作流程。当请求模板时，除非请求了特定版本，否则将返回此发布的版本。

存储后端

Heater 的存储后端应该是可配置的，但应支持基本的 CRUD 以及版本控制。可能的参考实现包括 Git 和 Swift。

初始实现

Rackspace 已经完成了一项类似服务的初步工作作为 POC。虽然一般的存储、版本控制、发布和元数据概念都存在，但当前的软件需要达到 OpenStack 标准，包括 API 实现、代码格式和身份验证。它还缺乏数据存储和标记的可配置性，但是，现有的代码可以与此规范保持一致，并且只需很少的努力。

Heater 不是

Heat 的代理
一个完整的模板 CMS
一个模板设计工具
专为单一用例而设计

Heat/htr

目录