Review scheduler retry logic for archive and retrieve
- Implementing a "try again after T seconds" mechanism is complex and requires playing with the current implementation of the object store.
- In particular, we would need to create a new queue subtype to keep track of the requests that we want to retry later. This is a non-trivial task.
- The new postgreSQL scheduler will make it much easier to implement this feature in the future (#147).
- Therefore, we will not implement this yet.
As a compromise, we will modify the number of retries to 0 (zero) in the case of repack requests, as discussed in the following topic.
Handle 'unavailable' files in user and repack retrieves originated from problematic tapes
- We discussed the two options presented in issue #218.
- Both options are not mutually exclusive. However, option #2 (do not retry when repacking) is much simpler to implement and operate, while option #1 (manualy disable some files on a problematic tape) is more complex and requires changing the catalogue.
- Therefore, we will implement option #2, but will keep discussing with our external collaborators if option #1 is also necessary.
Amend code convention: include headers should use the complete path from the project root
- It was decided that we will change all the headers to full path.
- Richard will handle it.
REPACKING tape state and queue cleanup
- Release 4.8.1-1 fixed successfully the protobuf bug introduced in 4.8.0-1. The monitoring data shows this.
Several Free drive STALE because of long global scheduler lock aquisition time
- We will only mark as STALE a free drive that did not update its status in the past 4 hours (increase from 10 mins to 4 hours).
- This change is only done in the client side (backend does not calculate this).
stagerrm issues continued
- There are several stagerrm-related issues in both our operations and development pages.
- We need to aggregate all of them and discuss a common approach.
- To be discussed between Joao, Julien and Richard.
Improvements in gitlab CI workflow
- The CI stage cta_valgrind has been taking a long time, and impacts the time that it takes to merge a commit into main.
- Therefore, we will remove cta_valgrind from the list of mandatory CI stages (will be kept as optional). It will still be done as part of the scheduled CI tests.
- The person tagging the release must check that the last commits passes the Valgrind tests. It must be written as a part of the checklist!
- Besides this, the file ReleaseNotes.mb is always a source of rebase conflicts. We need to think of a strategy to avoid this conflicts (for example by clearly separating each person's commits in different files, or in different segments of the same file).
CTA Dev Meeting
