这是Ceph开发每周谈的第八篇文章，记录从16年1月25号到16年1月31号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
-
上周综述
上周末社区经理 Patrick McGarry 宣布 Ceph Developer Summit 变更为 Ceph Developer Monthly，此举意在增加 Ceph 主要开发者的沟通频率，避免 release 期间过长的空档期使得新的特性和一些旧问题迟迟得不到广泛讨论，这也意味着 Ceph 社区希望进一步加速特性迭代速度和 Bug 修复间隔。这次 CDM 将会在 Feb 3 举行。
-
Firefly 寿终正寝
Firefly 在 2014 年五月份发布，是 Ceph 的里程碑式的版本，增加了 Cache Tiering，一系列性能优化和稳定性支持，这个版本也是 Ceph 被广泛使用的第一个版本。Ceph 每年发布两个版本，上半年发布 LTS(Long Term Support)版本，下半年发布开发稳定版本，LTS 跟 Ubuntu 的概念类似，将会提供两年的 Bug 修复 Backport 支持，并且社区会持续测试，保证升级的稳定性。通常来说，生产系统最好运行在 LTS 版本上来获得长期支持。而开发稳定版本如 G，I 版本则提供短期支持(一年左右)，开发稳定版本更适合作为内部测试环境，提供了更快的特性预览和性能提升。这个机制使得 Ceph 社区大部分只需要维护一个 LTS 版本和一个开发稳定版。有效避免了历史版本的支撑问题。
因此，仍处于 Firefly 版本的集群需要尽快升级到 Hammer 版本，主要是社区升级测试的支撑很快会从 Firefly 版本结束，为了避免下一个 Hammer 版本引入一些升级问题。同时，实际上，社区”偷懒”在三个月前已经停止 backport bug fix 到 firefly，因为由于版本差异巨大，backport 成本和测试成本太高导致。
-
OSD 额外 ceph.conf 支持
众所周知，基本上用户都依赖 /etc/ceph/ceph.conf 作为配置文件启动 Ceph OSD，但是在融合场景和其它特殊情况(包括上期提到的系统盘挂掉问题)都使得我们也需要让 OSD 能够自动链接其它 ceph.conf 文件来启动，更准确的来说，需要让额外 ceph.conf 启动自动化，而不是依赖 -c configfile 来配合。因此，Sage Weil 上周提交了两个 Pull Request，一个是优先找到本地(本地数据目录)的配置文件，另一个是允许多配置文件加载并覆盖，由于 Ceph 本身的配置系统就比较复杂，后者会导致更加混乱的选项优先级关系，很可能导致 OSD 启动使用了用户并不期望的值，因此后者被废弃，前者会合并到主线。