From 86ac060b473699a1d512204f3eebfe05ee0be3c8 Mon Sep 17 00:00:00 2001 From: moooofly Date: Wed, 20 Jun 2018 17:22:18 +0800 Subject: [PATCH] chore: update doc --- ...\245\347\232\204\350\256\250\350\256\272.md" | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git "a/docs/\345\205\263\344\272\216\346\270\205\347\220\206\347\255\226\347\225\245\347\232\204\350\256\250\350\256\272.md" "b/docs/\345\205\263\344\272\216\346\270\205\347\220\206\347\255\226\347\225\245\347\232\204\350\256\250\350\256\272.md" index c0ac6e2..85b8233 100644 --- "a/docs/\345\205\263\344\272\216\346\270\205\347\220\206\347\255\226\347\225\245\347\232\204\350\256\250\350\256\272.md" +++ "b/docs/\345\205\263\344\272\216\346\270\205\347\220\206\347\255\226\347\225\245\347\232\204\350\256\250\350\256\272.md" @@ -22,12 +22,13 @@ 我： -> 你这个需求算是比较特殊的，因为很多 repo 是需要保留多个 tag 版本的（以便回退之类的），所以，如果你的需求就是保留最后一个 tag ，那我建议你可以在 push 前，先触发一次删除操作；“有些 image 比较稳定没什么变动, 有可能超过 60 天没有修改, 但是却一直在使用”，这个需求可以根据策略进行保留，目前的策略是额外保留 10 个，满足你的要求； +> - 这个需求算是比较特殊的，因为很多 repo 有保留多个 tags 版本的需要（以便回退），所以，如果你的目标需求是仅保留最后一个 tag ，那我建议你可以在 push 前，先触发一次删除操作； +> - “有些 image 比较稳定没什么变动, 有可能超过 60 天没有修改, 但是却一直在使用”，这个需求可以根据策略进行保留，目前的策略是额外保留 10 个，满足你的要求； 我: -> 针对一些超级变态的 repo ，例如每天都能创建 5+ tags 的 repo（60 天就有 300+ 了），我会单独进行特殊处理；如果觉得自己负责的 repo 有 tags 保留策略方面的问题，请及时和我沟通…… +> 针对一些超级变态的 300+ tags 的 repo ，例如每天都能创建 5+ tags 的 repo（60 天就有 300+ 了），我会单独进行特殊处理；如果觉得自己负责的 repo 有 tags 保留策略方面的问题，请及时和我沟通…… 路人丙： @@ -35,7 +36,9 @@ 我： -> images 是保存在 S3 上的；针对 tags 来说，有些操作会基于 Harbor API 进行遍历，故存在效率问题；有可能导致某些操作的时长线性增长（目前大致估算，在 Harbor v1.2.2 版本上 60+ tags 在 UI 上手册展开在 7~12 秒左右），所以没用的 tags 都应该进行清理；Best Practice 应该是每个 project 或 repo 的负责人自行负责 tags 的清理，但目前还是由我统一先处理吧； +> - 目前 images 是保存在 S3 上的； +> - 针对 tags 太多的问题，怀疑有些 API 操作是基于 Harbor API 进行的遍历，可能导致执行时间随 tags 数量线性增长（在 Harbor v1.2.2 版本上 60+ tags 在 web UI 上首次展开在 7~12 秒左右），所以没用的 tags 都应该进行清理； +> - Best Practice 应该是每个 project 或 repo 的负责人自行负责 tags 的清理，但目前还是由我统一先处理吧； 路人丙： @@ -63,10 +66,10 @@ 我： -> @路人丁 目前针对 tags 的处理策略（见上面）就等价于不会完全删除掉 image ； -> @路人丙 目前写了 [moooofly/harbor-go-client](https://github.com/moooofly/harbor-go-client) 项目用于处理这个问题（因为官方尚不支持这个功能）； -> 针对“比如写个 crontab 脚本之类的”，目前我觉得不太需要定时执行，目前我可以每隔 15 天跑一次分析，然后再执行清除操作，可以不需要相关人员操心； -相关人员可以提一下关于处理策略方面的建议：比如 “针对 tag ：保留 60 天内创建的所有 tag ，在 60 之前创建的 tag ，额外保留 10 个；” 这个策略是否合适； +> - @路人丁 目前针对 tags 的处理策略（见上面）就等价于不会完全删除掉 image ； +> - @路人丙 目前写了 [moooofly/harbor-go-client](https://github.com/moooofly/harbor-go-client) 项目用于处理这个问题（因为官方尚不支持这个功能）； +> - 针对“比如写个 crontab 脚本之类的”，目前我觉得不太需要定时执行，目前我可以每隔 15 天跑一次分析，然后再执行清除操作，可以不需要相关人员操心； +> - 相关人员可以针对处理策略提建议：比如 “针对 tag ：保留 60 天内创建的所有 tag ，在 60 之前创建的 tag ，额外保留 10 个；” 这个策略是否合适； 路人戊：