ClickHouse / ClickHouse/clickhousectl

Correct service scaling and backup configuration help

Open
#848 0 comments 0 reactions 0 assignees View on GitHub
cloud documentation
Dominant language
Rust
Stars
74
Forks
5
Avg merge
2d 11h
Merged PRs (30d)
196

Description

## Validated scope and current-PR plan — 2026-09-11

This section records the QA review and the current decision to finalize existing PRs without opening new PRs. It supersedes the proposed routing/fix suggestions in the original report below; the original observations are retained. Central plan: #757.

### Work for the existing PRs

Implementation status: the checked sub-items below are implemented on the existing PR branches and validated locally on combined head `82b374816a917cbac3a68194659beaaa5c7c9087`. Required final-head Cloud CI and merging remain pending; this issue stays open. See #757 for the combined validation and CI status.

- [x] #792 — Fix indentation of the settings-set and query-endpoint-create CONTEXT blocks; extend structural help coverage to catch the inconsistency. Do not add wording-pinning tests.

- [x] #819 — Document entry `id` and `isActiveNow` as response-only alongside `baseConfig`, while keeping the agent context within its line budget.

### Remaining scope

Replica-limit help, command descriptions, backup-retention guidance, Query API access-control documentation and wake-error guidance remain deferred.

This is a partial assignment. Keep the issue open after these PRs land; use sub-item references rather than a whole-issue closing keyword.

### Validation and corrections

Schedule help really omits entry id/isActiveNow; structural help tests do not check indentation. The snapshot refreshed by #822 has max replicas 50, while CLI help still says 20: correct CLI docs separately from that API-library PR. Keep tier caveats. Query help already has eight content lines: replace or move a line rather than appending a ninth. Verify the IP-allowlist distinction for the Query API auth path and avoid claiming that all access controls are bypassed. Wake guidance and other service help changes are new scope.

---

## Original QA report

Found in the 2026-09-11 QA sweep of the combined PR stack at [`d2c37f81`](https://github.com/ClickHouse/clickhousectl/commit/d2c37f814fff53fe68d636e34103e2d0550bf84d), top PR #823, installed release build (package version still 0.4.2). Reproduced behaviour only; no implementation included.

Severity: low-medium; batch for `services.rs` help text.

1. Five doc comments (`create` and `scale`: `--num-replicas`, `--min-replicas`, `--max-replicas`) say "(1-20)". The OpenAPI spec says maximum 50, tier-dependent, enforced server-side, and the API accepted and ran `--num-replicas 21`. The CLI must not invent server limits; drop or correct the claim. (No client-side range check wanted — the API rejects memory/idle bounds with clear messages.)
2. `update — Update service settings` collides with the sibling `settings` subcommand (which is what actually manages ClickHouse settings); `scale — Update replica scaling` hides memory, idle-scaling and idle-timeout, which is where users look for "change the idle timeout" (and `update --idle-timeout-minutes` gives clap's `-- --idle-timeout-minutes` tip). Suggested: `update — Update service configuration`, `scale — Update service scaling and idle behaviour`.
3. `scaling-schedule get --json > s.json && scaling-schedule set --file s.json` fails: `unknown fields baseConfig, entries.0.id, entries.0.isActiveNow`. Help warns only about `baseConfig`; README lists all. Add `id`/`isActiveNow` to the help line (or ignore response-only fields on input). Entry field names are undiscoverable from `--help`.
4. `--backup-retention-period-hours` has no range; API enforces 24–1080. Sibling flags on the same screen state theirs.
5. `service settings set` and `service query-endpoint create` are the only two of 91 CONTEXT blocks whose body is not indented two spaces — reproduced live, different code path.
6. `cloud service query` is not subject to the service IP allow list (verified: list locked to one /32, `query` still worked). Security-relevant surprise worth one line on `query --help`.
7. `wake --help` explains that a stopped service needs `start`; the runtime error for that case (`BAD_REQUEST: Service must be in idle state to awake`) does not.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the validation and CI status in #757 and the existing PRs #792 and #819; the issue says not to open duplicate work. For deferred items, read the service help in services.rs, its structural help tests, and the README, then verify the remaining help and runtime guidance against the stated API behavior and final Cloud CI results.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cli, documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.