fluxcd / flux2

Review and enforce CRD Validation

Summary of Open Issue: Review and Enforce CRD Validation in FluxCD

Issue Overview: This issue aims to enhance the CRD (Custom Resource Definition) validation within the FluxCD project in preparation for the maturation of the APIs. The key actions include reviewing and enforcing validation across the various controllers within the Flux ecosystem.

Controllers Involved:

  • Source Controller
  • Kustomize Controller
  • Helm Controller
  • Notification Controller
  • Image Reflector Controller
  • Image Automation Controller

Key Actions to Implement:

  1. Leverage Kubebuilder for Validation: Implement validation using Kubebuilder annotations and add corresponding tests, for example, as demonstrated in pull request helm-controller#520.

  2. Field Requirements: Ensure that .Spec fields are appropriately marked as required across all CRDs.

  3. String Field Constraints: Define maximum length and patterns for string fields wherever feasible.

  4. Reference Types Utilization: Utilize and enhance validation for reference types from the pkg repository (specifically meta/reference_types.go), which currently only enforces presence via +required.

Contributor Engagement: Contributors are encouraged to take ownership of specific tasks. There has been active interest from contributors regarding how to approach the validation process, particularly concerning:

  • Specific validation for ValueKey and TargetPath fields.
  • Guidance on setting maximum and minimum length properties for string fields.

Ongoing Discussion & Collaboration: The issue has prompted a collaborative dialogue among contributors for clarification on validation requirements and testing strategies. One contributor has expressed interest in focusing on the notification controller as part of this effort.

Labels: The issue is categorized as “good first issue” and “help wanted,” indicating it is suitable for newcomers and those looking to assist.

Next Steps:

  1. Review existing CRDs across all controllers.
  2. Implement and propose validations on a case-by-case basis.
  3. Document validation rules to ensure consistency and clarity as work progresses.