User Details
- User Since
- Jul 10 2018, 12:38 PM (145 w, 6 h)
Today
So what about exports of the archive available on git-annex?
Note that there is the same transient vs cumulative discrepency on the "Accepted requests" graph.
I think the "submitted requests per visit type / status" graph should be split in 2 parts. Both accepted and rejected are cumulative values that will indefinitely grow, while pending are transient value aiming at staying near zero, so it makes no sense to have them on the same graph.
Yesterday
rebase
rebased
rebased
The loading tasks created during this first listing were oneshot tasks. So they have been modified to recurring tasks with something like:
Doesn't this deserve a state-of-the-art kind of thing? Are there documentation material on the subject? How does other (big) cassandra users handle this?
The listing task has been disabled, I think because of failures in the last executions:
is there a grafana dashboard dedicated to this queue?
also: what about exports we provide on git annex?
do we also intent to have a takedown topic on kafka?
Fri, Apr 9
Thu, Apr 8
Just got this one below. Note that this occurred just when the replayer actually started to insert object in the storage (before that, since the start of the replayer process, only kafka scaffolding took place for quite some time, around 30mn!)
Wed, Apr 7
looks like there is no revision with date or committer_date > 9999-12-31 in the main storage...
Tue, Apr 6
fix commit message
rebased
Add explicit checks for extid being written in the journal and split the revision in 2
Fri, Apr 2
Currently, the mirror test session is running with:
easy fix: modify the replayer to ignore this 'metadata' column while inserting revisions
09:45 <+vlorentz> douardda: yes and the only way around it (short of dropping data) is T3089 09:46 -swhbot:#swh-devel- T3089 (submitter: vlorentz, owner: vlorentz, status: Open): Remove the 'metadata' column of the 'revision' table <https://forge.softwareheritage.org/T3089> 09:46 <+vlorentz> or switching to cassandra 09:46 <+vlorentz> the good news is, they couldn't be inserted in the storage either, so you can safely drop them for now
Thu, Apr 1
Wed, Mar 31
Tue, Mar 30
Mon, Mar 29
looks indeed reasonable (both the 1. point and the code) thanks
Fri, Mar 26
rebase
rebase
rebased
apply vlorentz comments
Thu, Mar 25
refactor a bit the test