cloudnative-pg / cloudnative-pg/plugin-barman-cloud
Add details to why the minio tenant headless service must be used over the normal clusterIP service
- 主要语言
- Go
- 星标
- 192
- 派生
- 75
- 平均合并
- 1 天 16 小时
- 30 天内合并 PR
- 18
描述
["The console service is for managing the tenant, while the hl service exposes the S3 compatible API. "](https://cloudnative-pg.io/plugin-barman-cloud/docs/object_stores/#minio-object-store)
the `-hl` service is a headless service. There is also a `minio` "normal" (clusterIP) service created. Why can't we used the "normal" service? Does the plugin have to connect to all of the pods behind the service? I have been testing with a single pod and it works with the normal service (not the headless version) but that may just be because there is a single pod. Can you update the docs to say why it can't use the normal service, if indeed that is the case? Thanks!
EDIT: Furthermore, how does https://cloudnative-pg.io/plugin-barman-cloud/docs/retention/ ("The Barman Cloud Plugin supports automated cleanup of obsolete backups via retention policies, configured in the .spec.retentionPolicy field of the ObjectStore resource.") square with https://cloudnative-pg.io/plugin-barman-cloud/docs/object_stores/#s3-lifecycle-policy ("Barman Cloud uploads backup files to S3 but does not modify or delete them afterward. ") ?
贡献指南
调研方向
从链接的 MinIO 对象存储和保留文档页面开始。验证为什么相比 ClusterIP service 必须使用 tenant headless service,并使保留策略的措辞与关于 S3 生命周期策略的表述保持一致。当文档清楚解释受支持的 service,并呈现一致的保留行为时,即视为完成。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- kubernetes
- 领域
- documentation
- Issue 类型
- 文档
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 停滞
- 描述清晰度
- 需要澄清
- 新手友好度
- 38/100