会议纪要记录者：@liuzhiqiang26 （https://gitee.com/liuzhiqiang26）
会议内容：
0.与会人员介绍
liuzhiqiang26：openeuler存储
chixinze,zhuohui，黄俊：ceph IO路径一致性和性能，rados，store，XSKY
jacksir：麒麟，服务器桌面环境和开源软件适配，对ceph感兴趣
Luorixin，冯春松,liuqinfei,zhangfeng，daizhiwei等：图灵解决方案，arm平台
guoxiaoqi： openeuler安全问题处理情况
mawei：统信软件，关注ceph适配
1.ceph基本运作情况介绍 责任人：@chixinze
纪要：
1）@chixinze讲解了当前ceph的基本工作
问题：ceph v12社区已经end of life，cve已经在该版本中不再维护；
社区只维护两年，两年后就不再维护，低版本的CVE该如何处理？
讨论：
- 根据不同分支采取不同的策略；master可能采用升级来解决；LTS采用适配补丁方式解决；
- 每个CVE如果有给出具体影响版本，就会把CVE提到指定版本，如果没有给出就需要开发来确认；
- 不是所有的CVE都有复现方式，有些可能很难复现；
- 无法判断CVE是否涉及，也无法判断适配合入CVE是否会对其它功能造成影响。
- 要保证开源用例的执行是ok的。
根因：
- ceph组件较多，当前社区无法都高质量看护；
- ceph社区看护时间是两年，小于openeuler社区，如何解决低版本ceph的cve问题？
三大应用场景：1） 块;2)对象：3）文件：
说明：committer职责：1）issue处理；2）PR的review：
ceph的模块划分committer看护：
- MON: 元数据服务；sunligang（之前搞分布式文件存储）
- OSD: 负责IO下盘；Luorixin，sunligang
- RGW: 对象网关；daizhiwei
- MDS: 文件元数据服务；sunligang
- RADOS: 抽象概念；chixinze
- RBD: 块的网关；daizhiwei
- kernel中的ceph：kernel rbd的client模块，ceph fs；暂不关注
后续可以考虑每次例会大家开展各个模块的分享；
2.如何提升ceph看护质量？ 责任人: 发散讨论
答：
- 确定各个模块责任范围，更多人参与看护
- ceph的make check是否考虑打开？
- 社区有相应的场景用例：https://github.com/ceph/teuthology。
3.确定后续ceph例会时间 责任人：发散讨论
答：
- 两周一次：周一，时间：20:00~21:00，时间最好控制在1小时内。
- 关注：dev@openeuler.org
4.安全委员会讲解一下 社区漏洞处理要求 责任人：@yanxiaobing2020, @angela7
@guoxiaoqi
答：@guoxiaoqi 讲解了openeuler中CVE的具体处理方法；
5.鲲鹏分布式存储组介绍其ceph相关工作 责任人：@liuqinfei
答：鲲鹏分布式存储在ceph的性能优化方面开展了一些工作，并推送到原生社区。
期望能够依赖openeuler社区将高版本补丁回合到低版本中，以更好地提升openeuler ceph的性能表现。
遗留问题：
1.在upstream中的ceph.spec.in中支持openeuler的编译，这样可以直接下载编译。
2.考虑引入社区ceph测试集：https://github.com/ceph/teuthology
3.剩余cve划分到各个committer来处理。（责任人：chixinze）
4.考虑每次例会大家开展各个模块的分享；
5.将各个模块划分的committer刷到ceph sig组的readme中。
会议纪要中附上 ceph sig组的微信号；欢迎对ceph感兴趣的小伙伴加入到ceph
sig组的微信群中（如果失效，可以先加微信：要唔要五六领悟九六三八 （转为阿拉伯数字哈））