On Fri, 13 Apr 2018 at 02:01:38 +0200, Guilhem Moulin wrote: > The next infra call will take place at `date -d 'Tue Apr 17 16:30:00 UTC > 2018'` > (18:30:00 Berlin time).
Reminder, it's in a bit more than 16h! > See https://pad.documentfoundation.org/p/infra for details; agenda TBA. Here is what we currently have in the agenda: * [Florian Reisinger (unable to participate) reisi007] + Can this folder [ https://dev-builds.libreoffice.org/daily/ ] be cleaned up. LibreOffice 4.2 to LibreOffice 5.3 have not been active for a while year. Same for Master tinderboxes. Accessing the "current" folder often results in a 4xx return code [ https://dev-builds.libreoffice.org/daily/master/Win-x86@39/current ]. Deleting such tinderboxes and branches would significantly reduce the server load, because currently I need to test every /current folder of every tinderbox to see if it is active! At the moment it seems like I am getting blocked from the servers because of the high number of useless request I have to make in order to check whether a tinderbox is active or not. Thanks for considering this! - G. *not* an argument not to cleanup, but FWIW dentries are buffered so the overhead should be minimal. also we're not blocking nor throttling peers with many requests, IMHO it's more likely that you've been affected by the network issue we current have at our datacenter - FYI if you have access to shell on that box, `find /srv/www/dev-builds.libreoffice.org/daily -mindepth 3 -maxdepth 3 -name current -xtype d -printf '/%P\n'` will do what you want - Alternatively `lynx -listonly -nonumbers -dump "$URL" | grep -Px "\Q$URL\E.+/" | sed 's,.*,output=/dev/null\nurl=¤t/,' | curl -w '%{http_code} %{url_effective}\n' -sIK-` (where URL=https://dev-builds.libreoffice.org/daily/master/ ) is pretty efficient (two HTTP connections for each branch; replace `grep -P` with perl or similar if your grep isn't GNU's) * Monitoring + Grafana and prometheus deployed on https://monitoring.documentfoundation.org + Do we want to install the node exporter on each VM? All recent VMs expose their state to the host through QEMU guest agent https://wiki.qemu.org/Features/GuestAgent and we could use that instead + Alerting: do we want that in prometheus, or on the Grafana panels? (so far only graph panels support that, but it should be possible with singlestats and table panels in later versions) + collectd: OK to remove from salt core, and uninstall from the VMs? + Exporters to look for, test and adopt: - libvirtd (so we see whether we overcommit RAM or vCPUs) - gluster: throughput, latency, healing stats - postfix: mail queue - RDBMS: slow queries, transactions - nginx: cache hits/misses, requests count, method, status code + Would be nice to expose the metrics from the blackbox exporter (or associated dashboards), not sure if that's feasible without exposing the whole prometheus data source * Bugzilla upgrade: currently hosted our last prod Debian 7 VM (codename Wheezy). Trash it and replace it with a fresh Debian 9 one from the new baseline? See you there -- Guilhem. -- To unsubscribe e-mail to: projects+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/projects/ All messages sent to this list will be publicly archived and cannot be deleted
