Expected Behavior
The Storage analyzer should not report a StorageClass whose provisioner is kubernetes.io/no-provisioner. That value is the standard marker for StorageClasses that do not support dynamic provisioning, used with local (static) volumes; it is not a deprecated provisioner.
Current Behavior
analyzeStorageClasses in pkg/analyzer/storage.go reports every such StorageClass with:
StorageClass <name> uses deprecated provisioner 'kubernetes.io/no-provisioner'
The check appears to conflate no-provisioner with the in-tree provisioners (kubernetes.io/gce-pd, kubernetes.io/aws-ebs, ...) that were deprecated as part of CSI migration. no-provisioner is a different case: it declares that the StorageClass does not support automatic provisioning and is the documented setup for local volumes, paired with volumeBindingMode: WaitForFirstConsumer.
A user with a legitimate local StorageClass therefore gets an error that misattributes their setup as deprecated, and the false positive also consumes an AI explanation.
Steps to Reproduce
Reproduced deterministically with the repository fake client (no live cluster required):
- Create a StorageClass with
provisioner: kubernetes.io/no-provisioner, as in the official example referenced below.
- Run the Storage analyzer (
k8sgpt analyze --filter Storage, or the existing TestStorageAnalyzer harness).
- Observe that the analyzer returns one error:
... uses deprecated provisioner 'kubernetes.io/no-provisioner'.
The existing test case named "Deprecated StorageClass" in pkg/analyzer/storage_test.go currently asserts this behavior.
Environment
- k8sgpt version: main (
731a6c9)
- Kubernetes version: n/a (analyzer logic; reproduced with fake client)
- AI Backend/Provider: n/a
- OS/Platform: n/a
Additional Context
Kubernetes documents local StorageClasses with exactly this provisioner; the official example includes the comment "indicates that this StorageClass does not support automatic provisioning":
Suggested fix: remove the no-provisioner check and turn the corresponding test case into a regression case asserting no error. A related concern (a local StorageClass set as the cluster default, where PVCs stay Pending) is a separate topic and out of scope here.
No matching open Issue or PR was found for no-provisioner or this StorageClass check.
I am willing to submit a focused PR after maintainer confirmation.
Note: drafted with AI assistance; the referenced code, documentation, and commit history were verified manually.
Expected Behavior
The Storage analyzer should not report a StorageClass whose provisioner is
kubernetes.io/no-provisioner. That value is the standard marker for StorageClasses that do not support dynamic provisioning, used with local (static) volumes; it is not a deprecated provisioner.Current Behavior
analyzeStorageClassesinpkg/analyzer/storage.goreports every such StorageClass with:The check appears to conflate
no-provisionerwith the in-tree provisioners (kubernetes.io/gce-pd,kubernetes.io/aws-ebs, ...) that were deprecated as part of CSI migration.no-provisioneris a different case: it declares that the StorageClass does not support automatic provisioning and is the documented setup for local volumes, paired withvolumeBindingMode: WaitForFirstConsumer.A user with a legitimate local StorageClass therefore gets an error that misattributes their setup as deprecated, and the false positive also consumes an AI explanation.
Steps to Reproduce
Reproduced deterministically with the repository fake client (no live cluster required):
provisioner: kubernetes.io/no-provisioner, as in the official example referenced below.k8sgpt analyze --filter Storage, or the existingTestStorageAnalyzerharness).... uses deprecated provisioner 'kubernetes.io/no-provisioner'.The existing test case named "Deprecated StorageClass" in
pkg/analyzer/storage_test.gocurrently asserts this behavior.Environment
731a6c9)Additional Context
Kubernetes documents local StorageClasses with exactly this provisioner; the official example includes the comment "indicates that this StorageClass does not support automatic provisioning":
Suggested fix: remove the
no-provisionercheck and turn the corresponding test case into a regression case asserting no error. A related concern (a local StorageClass set as the cluster default, where PVCs stay Pending) is a separate topic and out of scope here.No matching open Issue or PR was found for
no-provisioneror this StorageClass check.I am willing to submit a focused PR after maintainer confirmation.
Note: drafted with AI assistance; the referenced code, documentation, and commit history were verified manually.