DevStack 日志记录和服務名称¶
注意:此规范仍在进行中,发布目的是为了尽早获得关于范围和步骤顺序的反馈。
https://blueprints.launchpad.net/tempest/+spec/devstack-logging-and-service-names
DevStack 需要更新其日志文件处理和服務命名,两者都适用于最初的屏幕式安装,其中只有少数幾個服務。
此规范同时包含日志文件重构和服務名称更新,因为它们之间有些关联,因此某些步骤将根据需要同时处理两者。
问题描述¶
DevStack 的日志配置最初基于保存 screen 日志,随着不再使用 screen 的开发,日志记录保持兼容,并且很明显最初的特殊情况不再需要。
从历史上看,DevStack 使用缩写的服務名称来标识要启用、命名日志文件以及在 screen 中作为窗口名称的服務。OpenStack 已经发展到缩写名称过于混乱且不明显的程度,特别是对于最近重命名的 Neutron。
这些主题在巴黎峰会上讨论过,相关笔记在 OpenStack Etherpad 中。
提议的变更¶
日志记录¶
更新 DevStack 的日志配置,以设置日志目录,而不是从文件名中解析出来。最终消除对 SCREEN_LOGDIR 的使用。
使用
LOGDIR作为 local.conf 中日志位置的主要设置,如果未设置LOGFILENAME,则默认为${DEST}/logs。如果设置了
LOGFILENAME,则继续使用。如果未设置LOGFILE,则继续将其设置为 $(dirname$LOGFILENAME)。弃用
SCREEN_LOGDIR并使用LOGDIR。为了兼容一段时间,在旧的 screen 日志位置保留符号链接。从服務日志文件名的开头删除
screen-服务日志文件将随着服务名称的更改隐式重命名(见上文)
Grenade 应该可以无缝工作,因为它允许 DevStack 运行执行其操作,并且 devstack-gate 包含所有需要更新的 Grenade 作业的特定内容。
服務名称¶
为服務名称使用完整的名称(如 ceilometer 今天所做):nova-compute、glance-registry 等。名称将使用项目名称,如在 devstack/lib/* 中使用的名称,后跟 ‘-’ 和服務的描述性名称。
还允许使用多个服務名称实例,例如,运行假 hypervisor 具有多个 nova-cpu 实例。将实例计数器附加到名称,类似于当前处理 n-cpu-N 的方式。可以选择使用 ‘:’ 作为服務名称和实例编号之间的分隔符。这将在日志文件名中使用,因此必须是 shell 安全的。
需要将旧的缩写名称映射到完整的名称,以处理向后兼容性。
这将使
ENABLED_SERVICES默认情况下非常长且难以视觉扫描。这是否是一个真正的问题? 借助最近强制升级到使用 Bash 4,我们可以使用关联数组一次性完成映射和启用列表。(注意:我们刚刚开始在 Grenade 中执行一些操作来处理缩写服務名称 -> 进程的映射 (https://review.openstack.org/#/c/113405/5/check-sanity) 这将有助于将该逻辑移动到 DevStack,并帮助提供其他映射(例如,服務名称 -> 数据库名称))
日志文件名将更改,但还有更多内容(见下文)。
在删除向后兼容性之前,需要更新 Grenade。
实现¶
负责人¶
- 主要负责人
dtroyer
工作项¶
日志记录:更改
SCREEN_LOGDIR中的日志文件名,以便带有时间戳的实际文件以时间戳结尾screen-c-sch.2014-12-10-193405.log becomes screen-c-sch.log.2014-12-10-193405
日志记录:更改
devstack-gate以查找*.log而不是符号链接来选择从screen-logs复制的日志文件。日志记录:从
SCREEN_LOGDIR切换到LOGDIR进行日志测试。这将把日志文件移出SCREEN_LOGDIR,因此在旧位置保留向后兼容的符号链接。(这是 #2 的原因,因为devstack-gate通过符号链接属性选择要复制的文件。)日志记录:在
devstack-gate中跟进,以直接使用 LOGDIR 并从那里复制日志文件。日志记录:一段时间后,删除
SCREEN_LOGDIR中的符号链接。服務:更改处理多个服務实例的方式,当前在
lib/nova start_nova_compute()和stop_nova_compute()中。如果更改了分隔符,配置文件名也会更改,请重新考虑是否需要解析。服務:构建新的服務命名结构和兼容性。
服務和日志记录:切换日志记录以使用新的服務名称,并确保
devstack-gate复制中不会丢失任何内容。
依赖项¶
唯一的依赖关系在于多个项目中所需更改的顺序。