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

Implement a removing worker #55

Open
derpeter opened this issue Oct 17, 2018 · 4 comments
Open

Implement a removing worker #55

derpeter opened this issue Oct 17, 2018 · 4 comments
Assignees

Comments

@derpeter
Copy link
Contributor

derpeter commented Oct 17, 2018

As we always fail to clean up when an event is done we need a worker that services the "removing" state of the tracker. This should be a second worker running on the same host as the publishing worker and and also share some code.

  • Service removing state
  • Make sure to only remove master encoding files when all subformats are released
    • We may need / want tracker support for this
  • Clean up encoded / tmp / capture / on the releasing host
  • Clean up on the encoder machines / storage is out of scope for now

@a-tze @jjeising RFC

@derpeter derpeter self-assigned this Oct 17, 2018
@jjeising
Copy link

Seems like a good idea! On the second thought, I see some open questions:

Clean up encoded / tmp / capture

On the releasing host encoded could be cleaned after a successful upload. tmp should probably be kept clean by the crs-scripts, and when it is cleaned, it should be scrubbed on a per project basis, not by individual ticket. Otherwise there would have to be a naming convention (e.g. folder with ticket id).

As far as cleaning capture I have major doubts this can be done on a per ticket basis. Even if we would identify the used segments these could also be used by other tickets and segments without usage would still remain.

I think this would be far more practicable (and less complicated) as a script triggered by a webhook on a per project basis. This could be triggered when archiving a project. Although I see this would be an issue for long running projects (for periodicals).

@derpeter
Copy link
Contributor Author

All folders mentioned are on the releasing host. For $reasons we have a capture dir there to.
I'm not sure why but tmp is not cleaned afterwards but it isnt.

But we could start with only cleaning /encoded/ and see where we go from there.
The main question is, how to figure when all subtickets are done.

Another option would be of course to enable the worker only when the trackerfahrer is sure ....

@a-tze
Copy link
Contributor

a-tze commented Oct 18, 2018

Not cleaning up the tmp folder is intentional. If only metadata changes, files from tmp will be tagged again and end up in encoded dir.
This may be implemented in another way but I'm not going to touch this to save some minutes of manual work per month.

@saerdnaer
Copy link
Member

Related Issue: #22

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

No branches or pull requests

4 participants