DongHyeonkaandClaude Opus 5
98a74e90a5
The forward upgrade to 26.7.3 was zero downtime across 87 samples, and since databasechangelog stayed at 210 the rollback to 26.7.0 also succeeded, which narrows D-2's conclusion: rolling back fails when the schema moved, not because of the version number. The row count is the check. Role changes never reach the upstream through request repetition; the session is a snapshot taken at login and only a new session picks up the new claim. Auditing the docs also surfaced that Prometheus scrapes only keycloak, kubelet, node-exporter and itself, so the B-layer experiments have no metrics to screenshot rather than missing screenshots. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
21 lines
689 B
Plaintext
21 lines
689 B
Plaintext
=== ★ 가설: 스키마 변경이 없으면 롤백이 된다 (26.7.3 → 26.7.0) ===
|
|
시작: 15:25:08
|
|
partitioned roll out complete: 2 new pods have been updated...
|
|
완료: 15:25:53
|
|
|
|
200 응답: 43 회 / 비200: 1
|
|
|
|
keycloak-0 1/1 Running restarts=0
|
|
keycloak-1 1/1 Running restarts=0
|
|
Keycloak 26.7.0
|
|
마이그레이션: 210
|
|
세션: 3
|
|
=== 롤백 중 응답 시계열 (비200 위치) ===
|
|
200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200
|
|
200 200 200 200 000 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200
|
|
200 200 200 200
|
|
비200 값: 000
|
|
|
|
=== 대조: 정방향 업그레이드 때는 ===
|
|
200: 87 / 비200: 0
|