feast-dev/feast

Integrate kube-api-linter (KAL) for Kubernetes API type validation in feast-operator

Open

#6062 opened on Mar 4, 2026

View on GitHub
 (2 comments) (2 reactions) (1 assignee)Python (5,029 stars) (896 forks)batch import
Operatorgood first issuestarter-ticket

Description

The feast-operator defines custom Kubernetes API types (FeatureStore CRD) in infra/feast-operator/api/v1/ and infra/feast-operator/api/v1alpha1/, but currently does not lint these types against the Kubernetes API Conventions. The kube-api-linter (KAL) from kubernetes-sigs can catch common mistakes and enforce best practices for Kubernetes API types automatically.

The feast-operator already uses golangci-lint (configured in infra/feast-operator/.golangci.yml), but none of the enabled linters are specific to Kubernetes API conventions.

KAL checks for issues like:

  • Required/optional field markers
  • Status subresource conventions
  • Condition and phase best practices
  • Proper use of metav1.Condition types
  • JSON tag and marker validation

Integrating KAL would catch API design issues early and reduce the manual review burden for API changes.

Proposed Changes

  • Add kube-api-linter as a golangci-lint module or plugin in the feast-operator.
  • Create a .custom-gcl.yml configuration to build a custom golangci-lint binary with KAL included.
  • Update infra/feast-operator/.golangci.yml to enable and configure kubeapilinter, scoped to the api/ directory.
  • Fix any existing violations surfaced by the linter.
  • Integrate the linter into CI to prevent future regressions.

References kube-api-linter repository: https://github.com/kubernetes-sigs/kube-api-linter

Contributor guide