-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Replication: avoid overlapping replication jobs #17269
Comments
Currently the replication jobs are launched and executed by |
For the design of harbor replication, from the server side all the tasks each other as independent individuals, so it's not suitable to add dependency with each other such as wait for previous task, that's too tightly coupled a mechanism. But to solve your issue, i think you could consider it from client side, for example, you could call harbor API to fetch task status and only trigger replication when match your customize conditions. |
@chlins I think that sequential processing of replication jobs makes sense at least if they are grouped per replication policy. Thanks for the suggestion with working through the API. I'll have a look into this. |
@chlins its been over a year, do we have any update on this topic - to enable sequential replications to a job? |
Yes, I am currently working on it. Since a lot of people facing this problem. Will soon raise a PR with changes needed to fix this. Thanks |
In one of our instances one of our users had a replication set up that, in combination with #16656, led to nearly a thousand running replication jobs.
None of which was able to finish.
The logs showed similar entries like #15415.
The replication pulled every few minutes from another registry and when delays occured it lead to an cascading effect where the first replications weren't able to properly finished but new jobs have been started nontheless.
In order to prevent this I would like the possibility to avoid starting new jobs when for a specific replication when there is already a replication running.
I think one way to address this is to switch the way jobs are spawned from a specified schedule to creating jobs X after the previous job has been finished.
The text was updated successfully, but these errors were encountered: