重新加载与启动
无需重启即可修改文件，以及启动时会发生什么
无需重启即可修改文件
种子每隔 CONFIG_SEED_RELOAD_SECONDS（默认 60，0 表示关闭）重新读取一次， 在其内容发生变化时重新应用。因此，提交到 git 的更改会自动到达 正在运行的实例：在 Kubernetes 上，ConfigMap 会在大约一分钟内重新挂载到 pod 下， 下一次检查就会读取到它。无需滚动发布，无需重启，也不需要 任何钩子去调用什么。
对于未改变的文件，轮询只计算一次哈希就会停止，因此它永远不会改写已经 应用过的行。
要立即应用文件而不是等待下一次检查，可以使用以下任一方式：
POST /api/v2/config-seed/apply # settings admin ; answers with what it did
kill -HUP 1 # inside the container, no credentials needed
两者都会 强制 应用，即使文件没有改变。强制应用会重新确立 直接在数据库中被编辑过的托管记录，并重新克隆缺少工作树的已声明仓库。
与启动时的应用不同，重新加载 永远不会是致命的。已经在 提供服务的实例会保持其当前配置，原因会被记录到日志中，状态页面上的 配置种子 行 会变红并指出原因。推送到 git 的一个拼写错误，不应该在没有任何运维操作的情况下 让正在运行的实例宕机。
同样损坏的内容也不会在每次检查时重试；否则一次错误的编辑就会 无限期地向日志写入同一条错误。请修复文件，或调用端点立即 重试。
损坏的种子会拒绝启动
无法读取的文件、无效的 YAML、未知字段、重复的名称或未解析的 ${VARIABLE} 会让服务器 退出 而不是启动。这只是 启动 时的 路径：同一个文件对已经运行的实例会产生什么影响，请参见上面的说明。
这是有意为之。继续使用之前的配置，会让实例的 行为不再与本应描述它的清单相符，而且没有任何东西 报告这种不一致。原因会同时写入标准错误和日志文件，因此 kubectl logs 和 docker logs 都能显示它。
验证是严格的：未知字段会被拒绝而不是忽略，错误会指出 有问题的键：
Config seed failed, refusing to start: Seed file validation failed: /awx/items/0 must NOT have additional properties 'tokenn'
空数据库会自行初始化
在 ALLOW_SCHEMA_CREATION 打开时（默认），完全没有任何 AnsibleForms 表 的数据库会在启动时创建其 schema。因此，全新的部署无需任何人 手动调用 /schema 端点即可启动。
这个前提条件是有意设得很严格的：创建 schema 会 先删除所有表，因此 它只会在完全为空的数据库上运行。缺少某一列的数据库，或者有表但没有用户账户的数据库， 都 不算 空，会保持不变；这些情况由 schema 补丁处理。