AlmaLinux Wiki

# ALESCo Meeting Minutes (2024-08-21)

Minutes recorded by Jonathan Wright.

Edited by Jonathan Wright for publishing.

# Members

# ALESCo Member Attendees

  • Jonathan Wright
  • Cody Robertson
  • Andrew Lukoshko
  • Elkhan Mammadli
  • Ben Thomas
  • Neal Gompa

# Board Attendees

  • benny Vasquez
  • Alex Iribarren

# Community Attendees

# Decisions Adopted

  1. SPICE support to be added back to AlmaLinux 10
    • Removed in RHEL 9
    • Will revisit for enablement in AlmaLinux 9 at a later time
    • Unanimous decision

# Minutes

  • SPICE Support in AlmaLinux
    • Neal: Dropped in RHEL due to no RHEL stacks dependent on it.
      • Cody: https://bugzilla.redhat.com/show_bug.cgi?id=2030592
    • We can package server-side components in AlmaLinux
    • We can package client-side components in EPEL
    • benny: Concerned about further deviation from RHEL
      • Retracted after clarification of no modifcations to kernel, and only addition of packages
    • Neal: Virt stack in RHEL remains relatively close to upstream, so good for maintainability of these additions
    • Neal: Upstream libvirt maintainers are good to work with, can probably propose running their CI against AlmaLinux Kitten 10
    • Voted to enable/build necessary packages for AlmaLinux 10 unanimously
    • Tabled discussion of adding back to AlmaLinux 9 at a later time
  • benny: ALESCo Live Community Q&A
    • No ALESCo members against this
    • Will be moderated by benny
    • Potentially quarterly
    • benny will coordinate a time that works for ALESCo members, maybe Sept. 4 or Sept. 11
    • Great for transparency and community engagement
  • Disabled HW in RHEL10
    • Andrew: What should we re-enable
      • All: Mellanox definitely
      • Andrew: 10s of devices disabled in EL10 kernel
      • Jonathan: QLogic & other less-used devices?
    • Neal: Linux Plumbers will be useful to make connections to RHEL kernel maintainers
      • They are generally willing to merge things for RHEL-disabled components as long as they don't impact enabled-components.
      • We probably need a separate process for users to request hardware enablement of devices
    • Ben: Already has requests within UCL for re-adding support for QLogic cards
    • Alex (Board): Must be careful when enabling things that might appear easy to flip a flag now but will potentially later become more difficult to maintain.
    • Jonathan: We can agree on an initial list of things to re-enable that are very common and/or we have direct experience with and vote on the rest as demand arises throughout the AlmaLinux 10 life cycle.
  • Elkhan: Separate kernel for PPC with KVM enabled
    • Neal: Basically what centos hyperscale does with their kernel - RHEL-ish config (based on Fedora) + enablement on some thingfs
    • Neal: What if we just re-enable it in the main Alma kernel since it is a flag?
      • Jonathan: We can mark that feature specifically as experimental, even in the main Alma kernel
      • Andrew: Just changing the flag isn't enough, a few patches are required to get it to build
    • Elkhan: Use-case is openQA and image building
      • All: not aware of any use-cases or requests from users
    • Ben: Separate workflow for kernel-specific requests?
      • Neal: fits within the other already-discussed to-be-defined change request processes
  • Andrew: Secure-Boot Signing ELRepo or other 3rd party kernels
    • Building works, signing works, never got further feedback on if we want to do this or not
    • Are we going to collaborate with 3rd party if we were to do this?
    • Neal: Anything we sign should be AlmaLinux-hosted
      • All: agreed on this point
    • Neal: Have discussed with Jonathan about also maintaing the Hyperscale kernel for AlmaLinux
    • Jonathan: Situation is too fluid right now to make a decision on this at the moment.
    • Jonathan: Better if we have a SIG that wants to maintain something within AlmaLinux versus pulling from a 3rd party
    • Neal: Signing SIG kernels in general
      • We have to be able to trust the full tree and trace back all changes to the origin
    • Jonathan: Motion to revisit this at a later time
      • All: agreed
  • Jonathan: Revisit ALESCo meeting times
    • Have heard from interested community members they cannot attend the current time of 10AM EST
    • Was difficult to select current time, tough to fit into ALESCo members schedules given varying countries/schedules
    • Neal: Potential compromise is scheduling the community Q/A sessions at varying times to be more accessible
    • Cody: Can re-run a discussion among ALESCo members to try to find a new time