New Proposal: Tag Retention Policies #4
Conversation
nlowe
force-pushed
the
proposal/tag-retention-policies
branch
from
a817fcc
to
4c25fc2
Compare
ghost
mentioned this pull request
steven-zou
added
status/reviewing
kind/proposal
area/registry
There was a problem hiding this comment.
@nlowe – apologies for the delay in reviewing; recently got back from vacation. I think this looks fantastic.
@steven-zou and @reasonerjt are on holiday next week, but let's aim to finalize and merge this proposal shortly after their return.
/cc @lweitzman – heads-up on something we'll need help mocking. 😄
|
@clouderati @nlowe Some of my thoughts : Most of the requirements are covered in the retention policies. I have the question regarding the scope of this policies. Are those policies configurable in project scope? . If it is project scope then it will be more helpful. |
|
@jakirpatel Yes, it is intended for project administrators to have control over filters for their projects if enabled at the server level. From the section on the filter chain:
|
|
Hi @nlowe – how do you feel about the state of this proposal? Pinging @goharbor/core-maintainers for a final review, else lazy consensus by October 26th and 👍 for merging and implementing. |
|
@clouderati From my perspective I think everything is covered. There hasn't been as much feedback as I would have expected (whether due to low exposure to the community or a general passive agreement with the proposal I'm not sure), but that's probably a good thing! |
ghost
mentioned this pull request
|
@nlowe no news is good news. @reasonerjt last chance for you and the team to chime in before code starts magically appearing. 😄 |
|
@nlowe – lazy consensus wins the day. Feel free to start hacking at your leisure. 😄 Any chance you can move the doc into the |
|
Sure thing. I need to fix the DCO check anyways. |
nlowe
force-pushed
the
proposal/tag-retention-policies
branch
from
37d9c48
to
77e4cb6
Compare
|
@nlowe – can you squash so I can merge? Thanks! |
Signed-off-by: Nathan Lowe <[email protected]> Signed-off-by: Nathan Lowe <[email protected]>
nlowe
force-pushed
the
proposal/tag-retention-policies
branch
from
77e4cb6
to
fc62c25
Compare
|
@clouderati Are there plans to merge this soon or is there something you'd like to see tweaked? I'd like to start work on this over the holidays when I have free time. |
|
Please take a look. If everything is ok, please approve it and I can merge it then. |
|
Looks great to me, +1 |
|
Implementation being tracked in epic goharbor/harbor#6654 |
Not many people have the luxury of unlimited storage. For images and tags that are effectively ephemeral (like those built and tagged for use only by an intermediate process in a CI pipeline) it does not make sense to keep these tags around for an extended period of time, consuming precious resources. Other tags, like those correlating to released or deployed software may need to be kept for an extended period of time or even forever for various legal or compliance reasons. While this is possible today via Harbor's API, Harbor Administrators could greatly benefit from having this functionality built-in to harbor itself.
This seems to be a relatively popular issue in the community today:
Created from goharbor/harbor#5882. Opened a PR with the proposal here at the request of @steven-zou.