rook/rook

Using encryptedDevice and host-based cluster, the OSD isn't resized when restarting it

Geschlossen

#13.262 geöffnet am 24.11.2023

Auf GitHub ansehenContributor Guide
 (13 Kommentare) (2 Reaktionen) (1 zugewiesene Person)Go (1.577 Forks)batch import
bughelp wantedkeepalive

Repository-Metriken

Stars
 (7.606 Sterne)
PR-Merge-Metriken
 (Durchschn. Merge 2T 23h) (170 gemergte PRs in 30 T)

Beschreibung

Is this a bug report or feature request?

  • Bug Report

Deviation from expected behavior:

  • Even after restarting the OSD deployments the size of the OSD is unchanged.

Expected behavior:

  • Resizing OSD by initContainers when the OSD is restarting.

How to reproduce it (minimal and precise):

  1. Setup the host-based cluster.
  2. Set spec.storage.config.encryptedDevice to true in CephCluster CR.
  3. Resize the disk that is using the OSD to larger than the OSD size.
  4. Restart the OSD.

File(s) to submit:

  • Cluster CR (custom resource), typically called cluster.yaml, if necessary

Logs to submit:

  • Crashing pod(s) logs, if necessary
    • The OSD pods are just starting fine.

Environment:

  • Rook version (use rook version inside of a Rook Pod): 
    rook: v1.12.8
go: go1.21.3
  • Storage backend version (e.g. for ceph do ceph -v): 
    ceph version 17.2.6 (d7ff0d10654d2280e08f1ab989c7cdf3064446a5) quincy (stable)
  • Kubernetes version (use kubectl version): 
    Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.3

Contributor Guide

Research-Richtung
Investigate the OSD provisioning code in the rook operator, specifically the initContainer logic for disk resizing. Compare the code path for encrypted vs non encrypted devices. Look for any condition that skips resizing when encryptedDevice is true. Check the comments in the issue for any maintainer suggestions.
Tech Stack
gokubernetes
Domain
infrastructuredevops
Issue Type
Fehler
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
4
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
Über 1 Woche
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
Go programmingKubernetesCeph storageRook operator
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
25