Skip to content

meeting 2023 02 02

Kenneth Hoste edited this page Feb 2, 2023 · 1 revision

Notes for 2023-02-02 meeting

  • date & time: Thu 2 Feb 2023 - 14:00 CEST (13:00 UTC)
    • (every first Thursday of the month)
  • venue: (online, see mail for meeting link, or ask in Slack)
  • agenda:
    • Quick introduction by new people
    • EESSI-related meetings in last month (incl. BioHackathon report)
    • First experiments with RISC-V
    • Progress update per EESSI layer (incl. bot for software layer)
    • 2021.12 version of pilot repository + outlook to next pilot version
    • AWS/Azure sponsorship update + OCRE funding opportunity
    • Update on MultiXscale EuroHPC project
    • Upcoming events
    • Q&A

Slides

Meeting notes

(by Kenneth and Bob)

Quick introduction by new people

  • Hyacinthe Cartiaux, University of Luxembourg
  • Killian Smith, HPCNow!

EESSI-related meetings in last month

(see slides)

EESSI project at BioHackathon Nov’22

Dates for next European BioHackathon have been published: « BioHackathon Europe 2023 will take place 30 October - 3 November at Campus Belloch, Barcelona. Details to be announced soon

First experiments with RISC-V

(see slides)

Progress update per EESSI layer

Filesystem layer

(see slides)

Compatibility layer

(see slides)

  • Alex: what does the version of the stack mean if you do updates of the compatibility and software layers?
    • Kenneth: It refers to when the stack was created. We try to limit the compatibility updates to the required ones w.r.t. security updates, and only add new software to the software layer. No big changes are being made to the layers themselves.
  • Alex: maybe we need a third digit in the version name to refer to the revision number?
    • Bob: that's actually an idea that crossed my mind as well when CVMFS had an issue with in-place updates (which has been fixed now), and also this morning when we hit the permission issue with the updated compatibility layer. Having the updated versions of the compat layer in different subdirs (2021.12-r1, 2021.12-r2, etc) with a symlink 2021.12 that points to the current version, you can easily and quickly switch (back) in case of issues (while still having the problematic version available for debugging). This could even been done with a variant symlinks, so that sites/users can switch themselves (Alex: that would help if, for instance, glibc gets updated and breaks local installations at a site that depend on that specific version). We just have to be careful that we then still provide the older (potentially vulnerable) versions of packages.
Software layer

(see slides)

Build-and-deploy bot

(see slides)

  • Thomas is looking for people who can help out with writing Python unit tests for the bot. Besides Kenneth (who's already involved in it), Jakob has experience with this as well.
EESSI pilot repository

(see slides)

AWS/Azure sponsored credits

(see slides)

  • ...

MultiXscale EU project

(see slides)

Q&A

(see slides)

Clone this wiki locally