stuff related to https://forge.softwareheritage.org/diffusion/DSTO/
Fri, Jan 15
Thu, Jan 14
Wed, Jan 13
Implemented in T2964
Mon, Jan 11
Thu, Jan 7
Sounds good to me.
Wed, Jan 6
Tue, Jan 5
Proposed manifest format:
Dec 9 2020
Question: who should be responsible for filling this table? The loader or the storage (as side effect of revision_add)?
Dec 8 2020
Ok so the plan is a first step as simple as possible, implementing what @olasd proposed in the task, put this table in the storage, and provide a simple batch get API endpoint.
Dec 7 2020
Thanks, this would be an important new feature. Some comments/random thoughts below.
Dec 3 2020
scope: mercurial will only need the mapping for revisions;
Dec 2 2020
After T2828, It's more clear of what must be deployed to have the counters working on staging:
- the counters can be intialized via the /stat/refresh endpoint of the storage api (Note: It will create more counters than production as directory_entry_* and revision_history are not counted in production)
- Add a script/service to execute the `swh_update_counter_bucketed` in an infinite loop
- Create the buckets in the object_counts_bucketed
- per object type : identifier|bucket_start|bucket_end. value and last_update will be updated be the stored procedures.
- configure prometheus sql exporter for db1.staging 
- configure profile_exporter on pergamon
- Update the script to ensure the data are filtered by environments (to avoid staging data to be included in production counts )
- Configure a new cron
- loading an empty file for historical data
- creating a new export_file
- update webapp to be able to configure the counter origin