xcat2/xcat-core#7864 adds openEuler 20.03 LTS SP4, 22.03 LTS SP4 and
24.03 LTS SP4 on x86_64, for the management node, service nodes and
stateful and stateless compute nodes. The support matrix does not list
openEuler at all.
Add one row per release, x86_64 only, and say which node roles the
support covers. Widen the Version column to fit the release names.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
The Operating System & Hardware Support Matrix carried eight hardware columns:
Power, Power LE, zVM, Power KVM, x86_64, x86_64 KVM, x86_64 Esxi and riscv64.
Six of them name a platform or a hypervisor, not a build target. xCAT builds and
ships one set of packages per architecture, so a reader cannot tell from the old
table which artifact serves a cell, and the same artifact appears under three
headings.
Reduce the columns to the three architectures xCAT builds for: x86_64, ppc64le
and riscv64. The x86_64, x86_64 KVM and x86_64 Esxi cells collapse into x86_64,
and Power, Power LE and Power KVM collapse into ppc64le. Every collapsed group
held one value per row, so no row changes meaning. The zVM column is removed:
s390x is not a built architecture.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
The aarch64 column advertises three EL targets that are outside the xCAT 2.19 campaign scope and creates unsupported campaign obligations. Remove the column so the documentation remains the exact source of truth for the release qualification backlog.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
The standalone riscv64 paragraph duplicated a version restriction that the versioned matrix now expresses directly and described only compute-node behavior. Keeping it would leave two sources for the same support claim.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
The operating-system support table named distro families without defining which releases the claim covered, and it kept separate legacy CentOS and Windows rows that are outside the xCAT 2.19 CI target contract. This made the release matrix ambiguous and impossible to translate into a finite CI backlog.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
The guides said riscv64 covered EL10 only, and the riscv64 page listed
Ubuntu as unsupported. Both support matrices now carry the architecture for
Ubuntu, and the riscv64 page describes the Ubuntu paths: the loader copycd
builds from the media, the installer needing none of the accommodations
EL10 requires, the ports archive the packages come from, and a management
node running on riscv64. The 26.04 media need the RVA23 profile, which is
recorded as a limitation.
Signed-off-by: Vinícius Ferrão <2031761+viniciusferrao@users.noreply.github.com>
Add the riscv64 page to the cluster management guide (UEFI + grub2 boot
path, discovery through mknb's grub2 network configurations, stateful and
stateless provisioning, the dependency picture for a management node on
riscv64, limitations), list riscv64 in the node object attributes and in
the support matrices, add the architecture to the cross-build page for
stateless images, extend the grub2 install guide (and fix its swapped
x86_64/aarch64 file names), the uninstall package lists, the DHCP backend
validation matrix and the mknb/genimage man pages, and carry the riscv64
schema values into the generated nodetype, osimage, noderes, node and
group references.
Daniel Hilst
Vinícius Ferrão
Markus Hilger
Mark Gurevich
Victor Hu