pingcap / pingcap/tidb-operator
validate storageVolumes field and fail the tc update if new volumn is added
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 1.3k
- Forks
- 540
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 18
Description
Feature Request
Is your feature request related to a problem? Please describe:
- create a tc without
tidb.storageVolumes
tidb:
baseImage: pingcap/tidb
replicas: 1
service:
type: ClusterIP
config: {}
# storageVolumes:
# - name: log
# storageSize: "2Gi"
# mountPath: "/var/log/tidblog"
- uncomment the
storageVolumespart and apply again(try to add storageVolumes) - tidb pod is terminated and no new pod created.
k describe sts output:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulDelete 21m (x3 over 6d23h) statefulset-controller delete Pod uat-tidb-tidb-0 in StatefulSet uat-tidb-tidb successful
Warning FailedCreate 10m (x18 over 21m) statefulset-controller create Pod uat-tidb-tidb-0 in StatefulSet uat-tidb-tidb failed error: Pod "uat-tidb-tidb-0" is invalid: spec.containers[1].volumeMounts[4].name: Not found: "tidb-log"
[root@72 PingCAP-master]#
this is caused by StatefulSet.Spec.VolumeClaimTemplates can not be updated
Describe the feature you'd like:
validate the tc and failed to update if new volumn is added
Describe alternatives you've considered:
Teachability, Documentation, Adoption, Migration Strategy:
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the TiDBCluster validation and StatefulSet update handling for storageVolumes. Reproduce the update described in the issue, then verify that adding a new volume is rejected before the StatefulSet changes and that the user receives a clear validation error.
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
- Mostly clear
- Newbie friendliness
- 35/100