Change Details

At least the metadata indexer should be, because currently, it is based on a journal client dedicated to creating one-shot tasks. This would: - simplify the stack by removing moving parts (scheduler, storage access db for content indexer...). - allow better monitoring (as we already have a grafana dashboard for journal clients) Additionally, it would be an opportunity to make sure indexation is always retried on error (currently, it isn't; and failing to index one object causes the whole batch to be lost).

Currently on the metadata indexer was implemented as one but it was dedicated to create one-shot tasks with an indirection on the scheduler. This would: - simplify the stack by removing moving parts (scheduler, storage access db for content indexer...). - allow better monitoring (as we already have a grafana dashboard for journal clients) - allow indexation to be retried [1] on error - stop one index computation failure to fail the full batch indexation Indexers: - [ ] origin intrinsic metadata - [ ] D8149: origin extrinsic metadata - [ ] D8147: mimetype and fossology-indexer content indexers

At least the metadata indexer should be, because currently, it is based on a journal client dedicated to creating one-shot tasksCurrently on the metadata indexer was implemented as one but it was dedicated to create one-shot tasks with an indirection on the scheduler. This would: - simplify the stack by removing moving parts (scheduler, storage access db for content indexer...). - allow better monitoring (as we already have a grafana dashboard for journal clients) - allow indexation to be retried [1] on error - stop one index computation failure to fail the full batch indexation Additionally, it would be an opportunity to make sure indexation is always retried on error (currently, it isn't; and failing to index one object causes the whole batch to be lost).Indexers: - [ ] origin intrinsic metadata - [ ] D8149: origin extrinsic metadata - [ ] D8147: mimetype and fossology-indexer content indexers