janhoy opened a new issue, #868:
URL: https://github.com/apache/solr-operator/issues/868
### Summary
Encode how an incoming issue is classified, reproduced, and routed. The part
that most needs writing
down is the cross-project boundary: this repo is the Kubernetes operator,
not the Solr search
server, and the two have separate threat models and separate issue trackers.
### Invocation, and the approval gate
`/triage-and-reproduce <issue>`, taking an issue number or URL. Bail out
immediately if the issue is a feature
request; this skill is for bugs.
It never writes to GitHub on its own: it produces one proposal, shows the
exact draft, and waits for
an explicit go. Outcomes:
- **Reproduced** — classification, the reproduction command, a label,
suggested reviewers.
- **Not reproducible** — a draft comment asking the reporter for what is
missing: operator,
Kubernetes and Solr versions, the SolrCloud spec, the generated manifest.
- **Duplicate** — the issue it duplicates, and a draft close-with-comment.
- **Not an operator bug** — where it belongs (`apache/solr`, the ASF
security process in
`SECURITY.md`, or a docs fix) plus a draft comment saying so.
Labels and reviewer suggestions apply to every outcome. Derive reviewer
candidates from activity on
the touched paths in the last 12 months (`git log --since=12.months
--format='%an' -- <path>`),
never from a hardcoded list.
### Classify first
`THREAT_MODEL.md` already draws the line this skill needs. It states that
the project "is **not**
the Solr search server" (§ line 27), puts "the managed Solr (search server)
and its clients" out of
scope (§2), and routes everything about the Solr HTTP API to the
`apache/solr` model (§3). The skill
should turn that into a usable decision procedure for ordinary bugs, not
only security reports:
- **Operator bug** — wrong StatefulSet/Service/CRD output, bad reconcile
behaviour, a rolling-update
or backup defect.
- **Solr bug** — reproducible against the same Solr image outside Kubernetes.
- **User misconfiguration** — the largest class, and the one where the
answer is a docs link.
- **Chart bug** — the manifest is right but the Helm value never reaches it
(see the
`_custom_option_helpers.tpl` trap in the `add-crd-field` proposal).
The useful discriminator: if the generated Kubernetes objects are correct
and Solr still
misbehaves, it is not an operator bug.
### Reproduce
`tests/scripts/manage_e2e_tests.sh` already provides the harness, with
sub-commands
`create-cluster`, `run-tests`, `destroy-cluster`, `kubeconfig` and flags
`-k` (Kubernetes version),
`-s` (Solr image) and `-i` (operator image). The skill should cover which
versions to pick, which
means being explicit that the defaults have drifted: the e2e script defaults
to Kubernetes
`v1.33.7`, while `hack/release/smoke_test/test_cluster.sh` defaults to
`v1.26.6` and pins its own
`kind`. Reproducing on the wrong one wastes a cycle.
It should also record that **the e2e workflow is permanently disabled in
CI** and reports as
skipped, so a local `make e2e-tests` run is the only evidence that exists,
and should be stated in
the issue or PR.
### Route
Where a triaged issue goes afterwards: the `apache/solr` tracker for
search-server behaviour, the
ASF security process in `SECURITY.md` for anything in the threat model, a
docs PR for
misconfiguration, or a labelled issue here. This repo has **no
`.github/ISSUE_TEMPLATE/`** — if the
triage procedure settles, a template capturing operator version, Kubernetes
version, Solr version
and the generated manifest would cut most of the back-and-forth, and could
be a follow-up.
---
🤖 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]
