Auto-rollback of failed upgrade fails with some resources
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- go, kubernetes
- Lĩnh vực
- devops, infrastructure
Hướng nghiên cứu
Bắt đầu tại pkg/client/actionclient.go, quanh dòng 291, và lần theo đường dẫn rollback tự động, sử dụng issue 224 được liên kết để làm ngữ cảnh. Tái hiện các lỗi PVC và ConfigMap được mô tả bằng các ví dụ Helm CLI, sau đó xác minh rằng một upgrade bị lỗi không còn đi vào vòng lặp rollback khi rollback bắt buộc không thể khôi phục các tài nguyên này.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
It seems that helm's force option for rollbacks (that this library uses here) does not deal well with some resources.
When using the stackrox operator the error looks like this:
rollback failed: failed to replace object: PersistentVolumeClaim "scanner-v4-db" is invalid: spec: Forbidden: spec is immutable after creation except resources.requests and volumeAttributesClassName for bound claims
core.PersistentVolumeClaimSpec{
AccessModes: {"ReadWriteOnce"},
Selector: nil,
Resources: {Requests: {s"storage": {i: {...}, s: "50Gi", Format: "BinarySI"}}},
- VolumeName: "pvc-a78c78d0-a692-47d6-b01a-be7f8d6ebd4a",
+ VolumeName: "",
- StorageClassName: &"standard-csi",
+ StorageClassName: nil,
VolumeMode: &"Filesystem",
DataSource: nil,
... // 2 identical fields
}
: original upgrade error: cannot patch "scanner-v4-matcher-config" with kind ConfigMap: "" is invalid: patch: Invalid value: "
{
"apiVersion": "v1",
"data": {
"config.yaml": {
"matcher": {
"vulnerabilities_url": "https://central.stackrox.svc/api/extensions/scannerdefinitions?version=dev"
}
}
},
"kind": "ConfigMap",
"metadata": {
[... snip ...]
}
}": json: cannot unmarshal object into Go struct field ConfigMap.data of type string
It may be easier to understand what is going on on the following example, since the issue also happens with helm CLI. It's just that while the CLI warns to exercise caution with this option, the helm-operator-plugins library uses force automatically and unconditionally.
Let's say I have a chart that contains just a PVC such as this:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc1
spec:
accessModes:
- ReadWriteOnce
{{- if .Values.badness }}
storageClassName:
nonsense: yes
{{- else }}
storageClassName: standard
{{- end }}
resources:
requests:
storage: 500Mi
Then I:
helm install --debug repro1 .
This works fine. Now I create any pod that uses the PVC to make it flip to a Bound state.
Then I try to apply a broken upgrade:
$ helm upgrade repro1 . --set badness=true
Error: UPGRADE FAILED: cannot patch "pvc1" with kind PersistentVolumeClaim: "" is invalid: patch: Invalid value: "{\"apiVersion\":\"v1\",\"kind\":\"PersistentVolumeClaim\",\"metadata\":{\"annotations\":{\"meta.helm.sh/release-name\":\"repro1\",\"meta.helm.sh/release-namespace\":\"default\",\"pv.kubernetes.io/bind-completed\":\"yes\",\"pv.kubernetes.io/bound-by-controller\":\"yes\",\"volume.beta.kubernetes.io/storage-provisioner\":\"rancher.io/local-path\",\"volume.kubernetes.io/selected-node\":\"kind-control-plane\",\"volume.kubernetes.io/storage-provisioner\":\"rancher.io/local-path\"},\"creationTimestamp\":\"2025-02-13T12:00:25Z\",\"finalizers\":[\"kubernetes.io/pvc-protection\"],\"labels\":{\"app.kubernetes.io/managed-by\":\"Helm\"},\"managedFields\":[{\"manager\":\"helm\",\"operation\":\"Update\",\"apiVersion\":\"v1\",\"time\":\"2025-02-13T12:00:25Z\",\"fieldsType\":\"FieldsV1\",\"fieldsV1\":{\"f:metadata\":{\"f:annotations\":{\".\":{},\"f:meta.helm.sh/release-name\":{},\"f:meta.helm.sh/release-namespace\":{}},\"f:labels\":{\".\":{},\"f:app.kubernetes.io/managed-by\":{}}},\"f:spec\":{\"f:accessModes\":{},\"f:resources\":{\"f:requests\":{\".\":{},\"f:storage\":{}}},\"f:storageClassName\":{},\"f:volumeMode\":{}}}},{\"manager\":\"kube-scheduler\",\"operation\":\"Update\",\"apiVersion\":\"v1\",\"time\":\"2025-02-13T12:00:38Z\",\"fieldsType\":\"FieldsV1\",\"fieldsV1\":{\"f:metadata\":{\"f:annotations\":{\"f:volume.kubernetes.io/selected-node\":{}}}}},{\"manager\":\"kube-controller-manager\",\"operation\":\"Update\",\"apiVersion\":\"v1\",\"time\":\"2025-02-13T12:00:41Z\",\"fieldsType\":\"FieldsV1\",\"fieldsV1\":{\"f:metadata\":{\"f:annotations\":{\"f:pv.kubernetes.io/bind-completed\":{},\"f:pv.kubernetes.io/bound-by-controller\":{},\"f:volume.beta.kubernetes.io/storage-provisioner\":{},\"f:volume.kubernetes.io/storage-provisioner\":{}}},\"f:spec\":{\"f:volumeName\":{}}}},{\"manager\":\"kube-controller-manager\",\"operation\":\"Update\",\"apiVersion\":\"v1\",\"time\":\"2025-02-13T12:00:41Z\",\"fieldsType\":\"FieldsV1\",\"fieldsV1\":{\"f:status\":{\"f:accessModes\":{},\"f:capacity\":{\".\":{},\"f:storage\":{}},\"f:phase\":{}}},\"subresource\":\"status\"}],\"name\":\"pvc1\",\"namespace\":\"default\",\"resourceVersion\":\"764382\",\"uid\":\"75dd22fc-06ea-4ee0-b9e5-76eb054c3c62\"},\"spec\":{\"accessModes\":[\"ReadWriteOnce\"],\"resources\":{\"requests\":{\"storage\":\"500Mi\"}},\"storageClassName\":{\"nonsense\":true},\"volumeMode\":\"Filesystem\",\"volumeName\":\"pvc-75dd22fc-06ea-4ee0-b9e5-76eb054c3c62\"},\"status\":{\"phase\":\"Bound\",\"accessModes\":[\"ReadWriteOnce\"],\"capacity\":{\"storage\":\"500Mi\"}}}": json: cannot unmarshal object into Go struct field PersistentVolumeClaimSpec.spec.storageClassName of type string
This is expected. Now in this case the library would try to roll back, but with the force option this fails:
$ helm rollback repro1 1 --force
Error: failed to replace object: PersistentVolumeClaim "pvc1" is invalid: spec: Forbidden: spec is immutable after creation except resources.requests and volumeAttributesClassName for bound claims
core.PersistentVolumeClaimSpec{
AccessModes: {"ReadWriteOnce"},
Selector: nil,
Resources: {Requests: {s"storage": {i: {...}, s: "500Mi", Format: "BinarySI"}}},
- VolumeName: "pvc-75dd22fc-06ea-4ee0-b9e5-76eb054c3c62",
+ VolumeName: "",
StorageClassName: &"standard",
VolumeMode: &"Filesystem",
... // 3 identical fields
}
And then we fall into the loop as described in https://github.com/operator-framework/helm-operator-plugins/issues/224
- Ngôn ngữ chính
- Go
- Star
- 59
- Fork
- 53
- Merge trung bình
- 1 ngày 10 giờ
- Pull request đã merge (30 ngày)
- 6
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Không có mẫu pull request
- Không có hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của operator-framework/helm-operator-plugins
-
Update to Helm 4Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 42/100
Tất cả issue của operator-framework/helm-operator-plugins
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
-
accepted bug wg/agentic-context
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
vllm-project/semantic-router#4922 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug] Extraction-mode autogen returns pod templates in random order for map-keyed CRDs, so deny and report messages change between runsCó thể đã có người làm @ManojLamani đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
kyverno/kyverno#17980 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
raised-by:reviewer
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 84/100
medici-finance/assay#2681 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug triaged
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
fullsend-ai/fullsend#8353 · 4 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày