Add more built-in validation and defaulting to the Solr CRDs
- Dominant language
- Go
- Stars
- 283
- Forks
- 148
- PR merge metrics
- No merged PRs in 30d
Description
Currently the Solr Operator does not have a lot of CRD Spec validations or defaults built in. Instead we rely on a first-step of defaulting the Spec in the controller code before anything else is done. This works, however it would be much better for the user for these checks and defaults to be built into the CRD.
The minimum supported Kubernetes version is `v1.19`, as of #320, which opens up a lot of the possible validation and defaulting options that have been added in recent kubernetes versions.
List of validation/default options:
https://book.kubebuilder.io/reference/markers/crd-validation.html
https://book.kubebuilder.io/reference/markers/crd-processing.html
https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation
https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the current controller-side Spec defaulting and the Kubebuilder and Kubernetes validation/defaulting references linked in the issue. Identify which existing Solr CRD fields lack supported schema checks or defaults, then verify that those behaviors are represented directly in the CRD and that controller behavior remains consistent.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100