Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deduplicate prune #148

Closed
wants to merge 2 commits into from
Closed

Conversation

mweibel
Copy link
Collaborator

@mweibel mweibel commented Nov 19, 2020

This PR is based on #147 (that's why those commits are in there as well. Will need to rebase after merging that PR).

This change ensures that the restic repository is always available and set on jobs which is required for the queue to be able to detect which jobs are running against which repository. It adds a test related to this case to document and ensure what the execution queue does works.

Additionally it refactors to have a type for the possible job types.

I'm not entirely sure if this solves #118 already. There's code (worker.go) which ensures a job isn't run if there's another exclusive job running or an exclusive job isn't running if there is any other job running.
However that same code also is probably misbehaving (I'd still have to check, or rather: one should write a test for this):

  1. job A (exclusive) is running
  2. meanwhile job B is added to the queue
  3. queue pops the job off the queue and checks if shouldRun -> false

At this point job B is never run, as it's gone from the queue and doesn't get re-added.
Correct me if I misinterpret the code please :)

Comment on lines +3 to +4
// Type defines what job type this is.
type Type string
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is highly confusing with the built-in Go's "type"

Suggested change
// Type defines what job type this is.
type Type string
// JobType defines what kind a certain job is.
type JobType string

@Kidswiss
Copy link
Contributor

With the additional information from the customer in #118 unfortunately just skipping if another one of these jobs is already running isn't the desired result here.

The main problem they want to solve is, that they have multiple backups pointing to the same repository which all have a prune job defined that runs weekly at random days. But they don't want the prunes to run for each definition, instead the operator should see that there are multiple prune definitions that all run during the same period (like weekly) and then only run it once.

@ccremer ccremer closed this Nov 30, 2020
@ccremer ccremer deleted the branch k8up-io:development November 30, 2020 16:07
@Kidswiss
Copy link
Contributor

Kidswiss commented Dec 1, 2020

@ccremer deleting the development branch killed this PR :D

We agreed in the call yesterday that it would still make sense to merge it...

@mweibel Can you open a new one this time to master? thx

@mweibel
Copy link
Collaborator Author

mweibel commented Dec 1, 2020

ah right that's the reason ;)
yeah, on it already 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants