stuff related to the mirroring infrastructure, protocol, and tooling used to maintain the Software Heritage mirror network
Details
Wed, May 11
credentials created following https://docs.softwareheritage.org/sysadm/mirror-operations/onboard.html#how-to-create-the-objstorage-credentials
Mar 25 2022
Mar 23 2022
Feb 7 2022
Is this page enough?
https://docs.softwareheritage.org/sysadm/mirror-operations/planning.html
Jan 27 2022
Seems moslty ok, even if these errors still pop now and then in the logs.
Jan 24 2022
Jan 19 2022
Jan 18 2022
Jan 4 2022
May 11 2021
May 4 2021
Apr 27 2021
docs !
Where should this information be available?
- on the main website
- docs
- a private location
Apr 23 2021
Apr 22 2021
These revisions are probably coming from https://gitlab.com/gitlab-org/gitlab-test (or a clone)
Ah fun, one of the revisions with this pb, on staging (ba3343bc4fa403a8dfbfcab7fc1a8c29ee34bd69) seems to have been crafted by https://gitlab.com/gitlab-org/gitlab-foss/-/blob/staging-26-fix_add_deploy_key_spec/spec/models/merge_request_diff_commit_spec.rb
Apr 21 2021
See T3170 (error generated by the same invalid kafka messages).
Apr 19 2021
Apr 8 2021
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!)
Apr 6 2021
Apr 2 2021
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