这是Mimic v13.2.x长期稳定版本系列的第四个修正版本。此版本包括v13.2.3顶部的两个安全修复程序。我们建议所有模仿用户升级。 如果您已经 升级到v13.2.3，那么从v13.2.2到v13.2.3的相同限制也适用于此 。
值得注意的变化
-
CVE-2018-16846：rgw：对max-keys / max-uploads / max-parts强制执行边界（问题＃35994）
- 新参数
rgw max listing results控制max-keysBucket列表操作的上限（ListBucket，ListBucketVersions，ListBucketMultipartUploads（max-uploads），ListMultipartUploadParts（max-parts）
- 新参数
CVE-2018-14662：mon：允许访问配置存储的限制上限
v13.2.3中的显著的变化
- mons的默认内存利用率有所增加
。Rocksdb现在默认使用512 MB的RAM，这
对于中小型集群应该足够了; 大型集群
应该调整它。此外，<cite style="box-sizing: border-box;">mon_osd_cache_size</cite>已经
从10个OSDMap增加到500个，这将为
大型集群转换为额外的500 MB到1 GB的RAM，而
对于小型集群则更少。 - Ceph v13.2.2包含一个错误的反向端口，这可能会导致mds在
从先前版本升级Ceph集群时进入“损坏”状态。
该错误已在v13.2.3中修复。如果您已在运行v13.2.2，则
升级到v13.2.3不需要特殊操作。 - 不再需要bluestore_cache_ *选项。它们被
osd_memory_target 取代，默认为4GB。BlueStore将扩展
和收缩其缓存以尝试保持在此
限制内。用户升级时应注意，这是一个
比之前的1GB bluestore_cache_size 更高的默认值，因此使用
BlueStore的OSD 默认会使用更多内存。
有关更多详细信息，请参阅BlueStore文档。 - 此版本包含升级错误http://tracker.ceph.com/issues/36686，
因为在恢复/回填期间升级会导致OSD失败。
可以通过在升级后重新启动所有OSD
或在所有PG处于“活动+清除”状态时进行升级来解决此错误。如果您已
成功升级到13.2.2，则此问题不会对您造成影响。展望
未来，我们正在为此功能开发一个干净的升级路径。
更新日志
- CVE-2018-16846：rgw：对max-keys / max-uploads / max-parts强制执行边界（问题＃35994）
- CVE-2018-14662：mon：允许访问配置存储的限制上限
