Minutes from the Tue Oct 20 infra call

classic Classic list List threaded Threaded
1 message Options
Guilhem Moulin Guilhem Moulin
Reply | Threaded
Open this post in threaded view

Minutes from the Tue Oct 20 infra call


1. guilhem
2. Brett
3. Emiliano
4. Cloph
5. wget
6. solarion


* Post-LibOCon insights
  + cloph: quality degrades when people had both screensharing and videofeed,
    had to recommend not stop webcam when screensharing at the same time. 
    something to investigate next time we use jitsi in a conference - didn't
    happen for all speakers though
  + cloph: would be nice to have a challenge-response setup in the lobby, the
    only thing we had right now was the person exposing their nick (free form)
    when knocking
  + cloph: "sticky" muting of others except the speaker is missing / locking
    screensharing to only the presenter is a lacking feature
    - EV: BBB has this feature (Paolo Vecchi has an instance, we can plan some
      tests there if needed), I don't know/feel the need to explore a new
      platform right now
      . wget: Arawa from Philippe Hemmel can help as well for BBB's
        scalability (they have been in charge of several large BBB deployments
        in French universities :))
      . guilhem: we need to platform suitable for telco, jitsi is perfectly
        suitable for that
        . Emiliano: perfectly agree, jitsi is more than fine for meetings
          Maybe in case of a conference again
          . Guilhem: registrations were done on SuSE platform; so if we had
            the registration list before hand we could have made authentication
            mandatory to join the room and kickout those who misbehave (like
            we'd do in an IRL event)
  + cloph: disable notification on client-side would be nice (for the screen
    doing recording)
  + CLI tool to grant/revoke moderation to specific users, terminate rooms,
    kick people, flush cache etc
    - Maybe doable via custom XMPP messages
    - EV: have the impression that jitsi isn't the right tool for that kind of
      thing, upstream doesn't seem interested (but maybe they wouldn't refuse
      a patch)
  + Also lack integration with a global schedule (BBB does have that feature)
  + Excess of money for this conference could be donated to jitsi — or
    tendered to implement some of the above — EV to propose that to BoD
    - Brett: Jitsi could use their saving the conference as some publicity,
      success story etc
    - wget: kinda reinventing the wheel/duplicating stuff that BBB would
      already offer
      . guilhem: enough difference in specific features/stuff useful in jitsi
        independently of being a conference orga tool
    - EV: unclear how much excess money have on the budget
  + Recording: cloph and Italo did recordings via OBS, they plus Mike will do
    the editing and will upload to video platforms
    - Had a talk or two on gonogo as well, dunno if these were recorded (if
      not then we don't have any recording of these)
    - wget: Why didn't we stream to YouTube?
      . We had only one YouTube account, so difficult to do with 3 rooms —
        lack of planing, we were caught by surprise
      . wget: Don't forget TDF is not on their own when they are unlucky. TDF
        has a trustable community. We share all the same boat :) The Asian
        community provided a Facebook stream. The community could have helped :)

* libvirt exporter (Brett's investigation)
  + https://github.com/AlexZzz/libvirt-exporter seems to be the more "proper"
    fork these days (C.f. the version previously linked project in the pad). I
    tested it out on a Buster host and it worked as advertised. Is it worth
    reimplementing the node exporters already do (and are officially
    supported!) It may be a pain to install the node exporter on each VM but I
    posit that maintaining a libvirt exporter would be much more work.
  + guilhem: Could use a loopback-bound node exporter on guest vm124,
    reachable from the host at using QEMU's hostfwd
    capability `hostfwd=tcp:`
  + Example node_exporter alerts that can be used:
    - Disk filling within 4h (might need some tuning to eliminate false
      predict_linear(node_filesystem_free_bytes[4h], 4*3600) < 0
    - CPU usage:
      100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 75
    - High memory usage:
      (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 80
  + Perhaps e.g. needrestart would be best for kernel version reminders?
    - g. have that already but wanted to have `uname -r` summary in grafana,
      maybe available from node-exporter instead
      . Brett: it is! node_uname_info{}
  + Benefit of running the node_exporter on each VM is that they must be
    responsive for `up` to pass whereas libvirt could be `up` but the vm in a
    broken state
    - g. don't think so, it uses a shared socket to talk to the guest (needs
      guest OS cooperation)
  + Guilhem: try it out next time guests need to be power-cycled (for instance now)
  + Don't even need libvirt exporter
  + Brett: can use a translation of the host-specific ports in the
  prometheus.yml for something more human readable can provision the entire
  /25 already, shouldn't cause be problematic

* planned upgrades:
  + Mediawiki: dunno if Dennis tried upgrading the testwiki to 1.35
    - no urgency, guilhem to upgrade as fallback at a later point in time
  + gerrit: upgrade to 1.3.2
    - cloph: best do that sometime between 14 to 22 nov
    - guilhem to announce and test upgrade path

* Lists migration from FDO
  + nothing new since the sept call, just lack of time
  + wget: glad to know the opportunity window is still open and FDO still
    anwers and has uploaded the files. \o/

* wget: Upgrade map was updated, all good on that front (chocolatey)
  + Can something be done to avoid the situation (upgrade map falling behind)
    happening again?
  + cloph: cross update (maj -> maj+1) doesn't happen too often, but the
    update is now a part of the release making receipe

* mirrorbrain → mirrorbits(?)
  + wget: will checksum URLs stay available? (appending .md5, .sha256, ...)?
    - https://get.videolan.org/vlc/2.2.4/win32/vlc-2.2.4-win32.exe?sha256
    - http://download.documentfoundation.org/libreoffice/testing/7.0.2/win/x86_64/LibreOffice_7.0.2.2_Win_x64.msi.sha256
    - same format, rewriting trivial to do, can keep them compatible.
    - .mirrorlist with human-readable stuff will change though

* wget: AskBot → Discourse migration
  + guilhem: via API (questions/answers/users + scrolling API - i.e. like
    cursor in db but using the elastic terms here - ) to avoid
    reverse-engineering the schema. SEO linking comes at the end.
    . wget: will ask Mauricio and Daniel to see if they have any updates in
      that test, otherwise, I volunteer here o/
  + guilhem: out of order replies: we need more threads to see if the issue
    was fixed or not :-)

* Solarion: lurking for now but would like to contribute now
  + physist, now coder at Google
  + was a sysadmin for a long time
  + possible project: https://github.com/etix/mirrorbits
    - [wget: is completely crazy about IPv6. Mirrorbits allows full IPv6 end
      to end compared to mirrorbrains, so... He is interested to see what's
      going out here, and intervene in order to reduce as much breakage as
      possible for chocolatey packages.]

* Next call: Tue Nov 17 at 18:30 CET (note the DST!)


To unsubscribe e-mail to: [hidden email]
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/website/
Privacy Policy: https://www.documentfoundation.org/privacy