janhoy opened a new issue, #867:
URL: https://github.com/apache/solr-operator/issues/867
### Summary
Adding a field to a CRD is the most repeated change in this repo — #571
(`SessionAffinity`), #790
(`enableServiceLinks`), #818 (pod `securityContext`), #811
(`volumeAttributesClassName`), #739
(additional volumes) — and every one walks the same path. Encode it as an
Agent Skill in
`.agents/skills/add-crd-field/`.
### Invocation and inputs
`/add-crd-field`, with a sentence or two of intent: what should become
configurable, and what
"working" looks like. A field name alone is not enough, because the file set
branches on three
answers:
- **Which resources?** SolrCloud, SolrPrometheusExporter, or both — decides
whether
`prometheus_exporter_util.go` and the second controller test are in scope.
- **Reachable from the Helm chart?** If yes, `values.yaml`,
`_custom_option_helpers.tpl` and the
README table are in scope; a CRD-only field skips all three.
- **How is it validated?** The assertion the new controller test should make.
Ask these as three short questions when they are not supplied, rather than
one free-text prompt —
each answer changes which files get touched. Stop and re-scope if the answer
implies controller
logic beyond plumbing a value into the PodSpec: that is a feature, not a
field.
### The actual file set
Taken from #790 (12 files) and #571 (15 files), which agree on the shape:
**Hand-written**
- `api/v1beta1/common_types.go` or `solrcloud_types.go` — the Go field and
its kubebuilder markers.
- `controllers/util/common.go` — plumbing into the PodSpec.
- `controllers/util/solr_util.go`, and `prometheus_exporter_util.go` when
the field applies to both
custom resources.
- `controllers/solrcloud_controller_test.go`, plus
`solrprometheusexporter_controller_test.go` when it applies to both.
- `helm/solr/values.yaml` — the Helm value, with its comment.
- `helm/solr/templates/_custom_option_helpers.tpl` — **maps the value into
`podOptions`. This is
the step contributors miss**; without it the value exists and does nothing.
- `helm/solr/README.md` — the values table. Hand-maintained, generated by
nothing.
- `helm/solr-operator/Chart.yaml` — the `artifacthub.io/changes` entry. Note
the asymmetry: the
value lives in the *solr* chart, but a CRD change is announced in the
*operator* chart.
- `docs/modules/solr-cloud/pages/custom-kube-options.adoc` — when the field
is worth documenting
beyond the values table (#571 did, #790 did not).
**Generated — never hand-edit**
- `api/v1beta1/zz_generated.deepcopy.go` (`make generate`)
- `config/crd/bases/solr.apache.org_solrclouds.yaml` and
`..._solrprometheusexporters.yaml`
(`make manifests`)
- `helm/solr-operator/crds/crds.yaml` (`make manifests`; a concatenation of
the above)
`make prepare` runs the generators in the right order. `make
check-manifests` diffs `config/` and
`helm/` recursively, so a partial regeneration fails CI.
### Why a skill rather than a CONTRIBUTING note
Every step is mechanical and every step is forgettable, but the failure
modes differ in how loudly
they fail. A missing regeneration fails CI immediately. A missing
`_custom_option_helpers.tpl`
mapping, a missing README table row, or a missing changelog entry all pass
CI and ship.
### Out of scope
- **A new custom resource, or a new API version** (`v1beta1` → `v1`).
Conversion and storage-version
work; nothing like adding a field.
- **Renaming, removing or retyping an existing field.** CRD fields are
public API, so those need a
deprecation cycle and the `deprecated`/`removed` changelog kinds.
- **Changing an existing field's default.** A behaviour change for existing
users, not an addition.
- **Controller behaviour beyond plumbing a value into the PodSpec**, as
above — that is a feature.
A field that makes the operator touch a new Kubernetes resource type stays
in scope, but the
resulting generated-RBAC change is user-visible and needs its own changelog
entry.
---
🤖 Issue text authored with AI assistance, approved by me
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
