Skip to content

[Bug] Storage analyzer reports local StorageClasses (kubernetes.io/no-provisioner) as deprecated #1774

Description

@bolubo

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):

  1. Create a StorageClass with provisioner: kubernetes.io/no-provisioner, as in the official example referenced below.
  2. Run the Storage analyzer (k8sgpt analyze --filter Storage, or the existing TestStorageAnalyzer harness).
  3. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    • Status
      Proposed

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions