add XFS StorageClasses

In the context of !9016 (merged) and !9184 (merged), we discussed the idea of having rustfs use upfront a PVC using XFS to avoid the inode limitation that proved to be a problem with MinIO ; with in mind that both have a similar design.

This MR takes inspiration from what had been discussed in !7409 but generalize the idea a bit further.

This MR introduces a Kyverno policy that will create an XFS StorageClass from each existing StorageClasses.

This allows to easily introduce the use of XFS-based filesystem: we can leave as-is the existing code that we have in various place to choose a StorageClass, the use of an XFS variant is then obtain by adding the -xfs prefix to it.

This MR makes use of the newer GeneratingPolicies introduced in recent Kyverno (but they would work as a Sylva 1.7 backport as well, because we have Kyverno 1.18 there).

Closes #4700 (closed)

Implementation details

The policy introduces is not applied to:

  • StorageClasses or whose provisioner is in the exempt list
    • this is required because changing the fsType does not make sense for some provisioners which aren't backed by a block device (local-path, NFS, ...)
  • StorageClasses that already use xfs as their fsType
  • StorageClasses that are themselves generated by this policy

Example

Here is an example in the Kyverno playground

CI example: see results in https://gitlab.com/sylva-projects/sylva-core/-/jobs/16786275661/artifacts/external_file/management-cluster-dump/StorageClasses.summary.txt

Development

This development was assisted by AI, but multiple iteration for refinements/simplifications, closely reviewed and heavily edited.

In fact GenAI (OpenCode + Sonet, sometimes Opus) proved to be a poor tool to help understand what is possible to do with CEL in Kyverno environment:

  • repeated attempts to use constructs that Kyverno CEL environment does not have (like + for map merges)
  • repeated attempts to use constructs that don't exist in CEL (like <map>.keys() or json.marshall)
  • repeated attempts to do things that were proven to not work
  • no proposal to use listObjToMap which ended up being the right tool for the job
  • no proposal to use <map>.map(k,k) to emulate the non-existing keys()

The tool wasn't able to understand that the GeneratingPolicy+MutatingPolicy was failing because the StorageClass.parameters is immutable.

I'm not sure that using 🤖 AI was the quickest...

CI configuration

Below you can choose test deployment variants to run in this MR's CI.

Click to open to CI configuration

Legend:

Icon Meaning Available values
☁️ Infra Provider capd, capo, capm3
🚀 Bootstrap Provider kubeadm (alias kadm), rke2, okd, ck8s
🐧 Node OS ubuntu, suse, na, leapmicro
🛠️ Deployment Options Deployment option list and description
🎬 Pipeline Scenarios Available scenario list and description
🟢 Enabled units Any available units name, by default apply to management and workload cluster. Can be prefixed by mgmt: or wkld: to be applied only to a specific cluster type
🔴 Disabled units Any available units name, by default apply to management and workload cluster. Can be prefixed by mgmt: or wkld: to be applied only to a specific cluster type
🏗️ Target platform Can be used to select specific deployment environment Available platform list and description
⚡ Pipeline control autorun, manual or blocking. Can be used to override global config and start a deployment pipeline the required way
  • 🎬 preview ☁️ capd 🚀 kadm 🐧 ubuntu

  • 🎬 preview ☁️ capo 🚀 rke2 🐧 suse

  • 🎬 preview ☁️ capm3 🚀 rke2 🐧 ubuntu

  • ☁️ capd 🚀 kadm 🛠️ light-deploy 🐧 ubuntu

  • ☁️ capd 🚀 rke2 🛠️ light-deploy 🐧 suse

  • ☁️ capo 🚀 rke2 🐧 suse 🎬 no-wkld

  • ☁️ capo 🚀 rke2 🐧 leapmicro

  • ☁️ capo 🚀 kadm 🐧 ubuntu

  • ☁️ capo 🚀 kadm 🐧 ubuntu 🟢 neuvector,mgmt:harbor

  • ☁️ capo 🚀 rke2 🎬 rolling-update 🛠️ ha 🐧 ubuntu

  • ☁️ capo 🚀 kadm 🎬 wkld-k8s-upgrade 🐧 ubuntu

  • ☁️ capo 🚀 rke2 🎬 rolling-update-no-wkld 🛠️ ha 🐧 suse

  • ☁️ capo 🚀 rke2 🎬 sylva-upgrade 🛠️ ha 🐧 ubuntu

  • ☁️ capo 🚀 rke2 🎬 sylva-upgrade-from-1.6.x 🛠️ ha,misc 🐧 ubuntu

  • ☁️ capo 🚀 rke2 🛠️ ha,misc 🐧 ubuntu

  • ☁️ capo 🚀 rke2|okd 🎬 no-update 🐧 ubuntu|na

  • ☁️ capo 🚀 rke2 🛠️ misc 🐧 ubuntu 🟢 mgmt:harbor 🔴 neuvector

  • ☁️ capo 🚀 rke2 🛠️ ha,misc,openbao 🐧 suse

  • ☁️ capo 🚀 rke2 🐧 suse 🎬 upgrade-from-prev-tag

  • ☁️ capm3 🚀 rke2 🐧 suse

  • ☁️ capm3 🚀 kadm 🐧 ubuntu

  • ☁️ capm3 🚀 ck8s 🐧 ubuntu

  • ☁️ capm3 🚀 kadm 🎬 rolling-update-no-wkld 🛠️ ha,misc 🐧 ubuntu

  • ☁️ capm3 🚀 rke2 🎬 wkld-k8s-upgrade 🛠️ ha 🐧 suse

  • ☁️ capm3 🚀 kadm 🎬 rolling-update 🛠️ ha 🐧 ubuntu

  • ☁️ capm3 🚀 rke2 🎬 upgrade-from-prev-release-branch 🛠️ ha 🐧 suse

  • ☁️ capm3 🚀 rke2 🛠️ misc,ha 🐧 suse

  • ☁️ capm3 🚀 rke2 🎬 sylva-upgrade 🛠️ ha 🐧 suse

  • ☁️ capm3 🚀 kadm 🎬 rolling-update 🛠️ ha 🐧 suse

  • ☁️ capm3 🚀 ck8s 🎬 rolling-update 🛠️ ha 🐧 ubuntu

  • ☁️ capm3 🚀 rke2|okd 🎬 no-update 🐧 ubuntu|na

  • ☁️ capm3 🚀 rke2 🐧 suse 🎬 upgrade-from-release-1.5

  • ☁️ capm3 🚀 rke2 🐧 suse 🎬 upgrade-to-main

Global config for deployment pipelines

  • autorun pipelines
  • allow failure on pipelines
  • record sylvactl events

Notes:

  • Enabling autorun will make deployment pipelines to be run automatically without human interaction
  • Disabling allow failure will make deployment pipelines mandatory for pipeline success.
  • if both autorun and allow failure are disabled, deployment pipelines will need manual triggering but will be blocking the pipeline

Be aware: after configuration change, pipeline is not triggered automatically. Please run it manually (by clicking the run pipeline button in Pipelines tab) or push new code.

Edited by Thomas Morin

Merge request reports

Loading
Loading