pingcap / pingcap/tiup

tiup cluster cdc should auto-fill TiCDC CLI server and TLS options

Open
#2,707 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
466
Forks
338
Avg merge
3d 7h
Merged PRs (30d)
8

Description

Feature Request

Is your feature request related to a problem? Please describe:

When TiCDC is deployed by tiup cluster with TLS enabled, users still need to repeat a long list of TiCDC CLI options every time:

tiup cdc cli changefeed query \
  --server https://<cdc-host>:8300 \
  --ca ~/.tiup/storage/cluster/clusters/<cluster-name>/tls/ca.crt \
  --cert ~/.tiup/storage/cluster/clusters/<cluster-name>/tls/client.crt \
  --key ~/.tiup/storage/cluster/clusters/<cluster-name>/tls/client.pem \
  --changefeed-id <changefeed-id>

For non-TLS clusters, users still need to manually find and pass the TiCDC API endpoint through --server. This is inconvenient and error-prone, especially when the cluster has multiple TiCDC nodes, manage_host, or TLS is rotated by tiup cluster tls.

Describe the feature you'd like:

Add a cluster-aware TiCDC CLI shortcut under tiup cluster, for example:

tiup cluster cdc <cluster-name> cli changefeed list
tiup cluster cdc <cluster-name> cli changefeed query --changefeed-id <changefeed-id>
tiup cluster cdc <cluster-name> cli capture list

The wrapper should load the TiUP cluster metadata and automatically derive common TiCDC CLI options:

  • Auto-fill --server from cdc_servers, preferably using manage_host when it is configured.
  • Use https:// when global.enable_tls is true, otherwise use http://.
  • When TLS is enabled, auto-fill --ca, --cert, and --key from the TiUP cluster TLS directory:
    • tls/ca.crt
    • tls/client.crt
    • tls/client.pem
  • For TiCDC CLI subcommands that still need PD access, such as tso query and unsafe reset, auto-fill --pd from pd_servers with the correct HTTP/HTTPS scheme.
  • Prefer a healthy TiCDC endpoint when multiple TiCDC nodes exist, and provide an explicit override such as --server or --node when users want to target a specific endpoint.
  • Do not override user-specified TiCDC CLI options. If the user explicitly passes --server, --pd, --ca, --cert, or --key, keep the user value.
  • Run a TiCDC CLI version that matches the cluster TiCDC version when possible, with an override for advanced users.

Why the featue is needed:

TiUP cluster already has the information needed to construct these options:

  • TLS status is stored in cluster metadata.
  • The client certificate paths are generated and displayed by tiup cluster display.
  • TiCDC and PD endpoints are available from the topology.
  • TiCDC CLI already accepts these options and also supports TLS-related environment variables.

Providing this shortcut would make day-to-day TiCDC operations much easier and less error-prone. It would also make runbooks and automation scripts simpler because users would not need to copy certificate paths or pick endpoints manually.

Describe alternatives you've considered:

Users can keep using tiup cdc cli ... directly with all options, but the command is long and easy to get wrong.

Users can store TLS options in ~/.ticdc/credentials or environment variables, but that is not cluster-aware and does not solve endpoint discovery. It can also become stale after TLS rotation or when switching between clusters.

Users can use tiup cluster display <cluster-name> to copy the certificate paths and node addresses manually, but this still requires repeated manual work.

Teachability, Documentation, Adoption, Migration Strategy:

The feature can be documented as a convenience wrapper around the existing TiCDC CLI. Existing tiup cdc cli behavior does not need to change.

Example documentation:

# Before
tiup cdc cli changefeed list \
  --server https://10.0.0.1:8300 \
  --ca ~/.tiup/storage/cluster/clusters/prod/tls/ca.crt \
  --cert ~/.tiup/storage/cluster/clusters/prod/tls/client.crt \
  --key ~/.tiup/storage/cluster/clusters/prod/tls/client.pem

# After
tiup cluster cdc prod cli changefeed list

The command should print or expose the resolved endpoint in verbose/debug mode so users can understand which TiCDC server is being used.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the existing tiup cluster and tiup cdc cli entry points, then inspect how cluster metadata and topology expose TiCDC, PD, and TLS settings. Define the wrapper's endpoint selection, option-preservation, TLS, version, and override behavior before implementing it. Done means the documented commands resolve the required options without replacing user values, including for TLS and multiple-node clusters.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cli, devops
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.