I think so, yes.

I think we can resolve this.
What do you think @ardumont ?

Add link to SWHID with context on the deposit-id.

Yannick has confirmed it works

Status:
UI and tests

Yannick hasn't answered yet. Will try again on the 15th.

Current status:
Following the last discussions, the current track I'm trying to implement is to create a grafana dashboard displaying the current status of the infrastructure.
To do so, some information managed by grafana should be displayed like the end-to-end checks status.

I think we can resolve this.
Checking with Yannick (HAL) that it works.

@anlambert here is another task to improve the deposit moderation/admin view

@anlambert here is the task we have briefly discussed as step 2 this morning

Deployed.

It resolved itself, it's green again.

Would you have time during September to help on this task? (it is a roadmap task, btw)

@anlambert we have discussed this task this morning with @ardumont and @vlorentz.
I want to start working on the improvements of the deposit admin view to open it up for deposit clients.
Would you have time during September to help on this task? (it is a roadmap task, btw)

Easiest option would be to add a link to the API endpoint.

The cleanup of the old counters is done so it can be closed

• D6064 landed
• manual cleanup:
  • the apache vhost was removed by puppet
  • /var/www/stats.export.softwareheritage.org directory removed
  • the crontab was removed by puppet
  • /usr/local/bin/export_archive_counters.py file removed
  • /usr/local/share/swh-data directory removed
• the refresh of the database counter is now scheduled each monday at 6:29 AM

postgres@belvedere:~$ crontab -l | grep counter
29 6  *   *  mon     /usr/bin/chronic /usr/bin/flock -xn /srv/softwareheritage/postgres/swh-update-counter.lock /usr/bin/psql -p 5433 softwareheritage -c "select swh_update_counter(object_type) from object_counts where single_update = true order by last_update limit 1"

For the counters frequency, I have still not found which cron/command regularly is responsible of lauching the refresh

Maybe looking around what calls the following functions could help.

For the counters frequency, I have still not found which cron/command regularly is responsible of lauching the refresh

Pergamon manual cleanup after D6064 is apply:

• Remove /var/www/stats.export.softwareheritage.org directory
• Remove apache vhosts:
  • /etc/apache2/sites-enabled/25-stats.export.softwareheritage.org_non-ssl.conf
  • /etc/apache2/sites-enabled/25-stats.export.softwareheritage.org_ssl.conf
  • /etc/apache2/sites-available/25-stats.export.softwareheritage.org_non-ssl.conf
  • /etc/apache2/sites-available/25-stats.export.softwareheritage.org_ssl.conf
• check crontab removal: export_archive_counters
• remove '/usr/local/bin/export_archive_counters.py'
• remove '/usr/local/share/swh-data' directory

The probe is deployed on the monitoring: https://icinga.softwareheritage.org/dashboard#!/monitoring/service/show?host=belvedere.internal.softwareheritage.org&service=Postgresql%20replication%20lag%20%28belvedere%20-%3E%20somerset%29

An example of a metadata icon for the deposit-admin view:
https://thenounproject.com/term/metadata/77940/