Spinnaker升级至1.35.1版本后管道消失问题分析

问题背景

在Spinnaker社区中，有用户报告了一个关键问题：当从1.34.3版本升级到1.35.1版本后，所有应用程序页面都显示"未为此应用程序配置管道"。这个问题主要影响使用GCS作为前端存储后端的自托管Spinnaker实例。

问题现象

升级后，用户观察到以下现象：

1. 所有应用程序的管道列表为空
2. 通过API调用获取管道配置返回空列表
3. 重启front50服务或强制刷新缓存均无效
4. 回滚到1.34.3版本后问题消失

根本原因分析

经过深入调查，发现问题源于front50模块中的一个关键变更。在1.35.1版本中，一个PR修改了数据文件的命名方式：

• 旧版本：所有对象类型都硬编码使用"specification.json"作为文件名
• 新版本：改为使用ObjectType枚举中定义的默认文件名

这个变更原本是为了统一命名规范，但意外导致了向后兼容性问题。具体表现为：

1. 在1.34.3及更早版本中，所有管道数据都存储在"specification.json"文件中
2. 1.35.1版本开始查找"pipeline-metadata.json"文件
3. 由于现有数据仍使用旧文件名，导致系统无法找到任何管道

技术细节

问题的核心在于StorageServiceSupport类中的文件命名逻辑变更。在旧版本中，代码直接硬编码了文件名：

private static final String DATA_FILENAME = "specification.json";

而在1.35.1版本中，改为动态获取：

private static final String DATA_FILENAME = ObjectType.APPLICATION.getDefaultMetadataFilename(true);

这种变更虽然从架构角度看更合理，但没有考虑到现有部署中的数据文件命名兼容性问题。

解决方案

Spinnaker团队迅速响应并提供了以下解决方案：

1. 紧急修复PR：恢复了向后兼容性，使系统能够同时识别新旧文件名
2. 热修复镜像：提供了包含修复的临时镜像供用户使用
3. 正式版本发布：修复已包含在1.35.3和1.34.5版本中

经验教训

这个事件为我们提供了几个重要的经验：

1. 文件命名变更需要特别谨慎，特别是在持久化存储方面
2. 版本升级前应充分测试数据兼容性
3. 对于存储后端变更，应考虑双读/双写过渡方案
4. 完善的监控指标（如cacheSize）对于快速诊断问题非常有帮助

结论

Spinnaker团队通过快速响应和修复解决了这个升级兼容性问题。对于遇到相同问题的用户，建议升级到包含修复的1.35.3或1.34.5版本。这个案例也提醒我们在进行存储格式变更时需要更加谨慎，确保不影响现有部署的数据访问。