The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.8 KiB
2.8 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, questionStatus, verifiedOn
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | questionStatus | verifiedOn |
|---|---|---|---|---|---|---|---|---|---|
| QUESTION | redis-topology-lane-not-executed | Redis 토폴로지 레인이 실행되지 않아 key spec 드리프트가 확인되지 않았다 | redis-command-admission | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | open-question:redis-topology-lane-not-executed | OPEN |
Redis 토폴로지 레인이 실행되지 않아 key spec 드리프트가 확인되지 않았다
명령 카탈로그가 전제하는 키 스펙이 실제 서버와 맞는지는 서버에 붙어야 알 수 있다. 그 레인을 이 리비전에서 돌리지 않았다.
사실
명령 메타데이터 드리프트를 검사하는 코드가 있다.
그 검사를 실행하는 Gradle 태스크도 CI 단계도 없다.
이 컨테이너에 Docker 가 있고 cache-redis 의 기본 test 레인은 435 테스트가 통과했다.
기동 탐침은 프로덕션에서 실행되지 않는다.
가정
기본 test 레인이 통과했으므로 카탈로그가 맞다고 전제하고 싶어지지만, 그 레인은 서버 메타데이터와 대조하지 않는다. 카탈로그가 스스로 일관적인지만 확인한다.
미지수
카탈로그의 키 스펙이 대상 Redis 버전의 실제 메타데이터와 일치하는가.
클러스터 구성에서 슬롯 계산이 실제 배치와 맞는가.
드리프트 검사를 지금 돌리면 무엇이 나오는가.
제약
컨테이너가 필요하다.
버전마다 결과가 다를 수 있으므로 대상 버전을 정해야 한다.
애플리케이션 소스를 수정하지 않는다.
선택지
드리프트 검사를 수동으로 돌린다 가장 직접적이다. 현재 드리프트 유무가 바로 나온다.
토폴로지 레인 전체를 돌린다 슬롯 계산과 커넥션 레인까지 함께 확인되지만 시간이 더 든다.
다음 검증
Redis 컨테이너를 띄우고 명령 메타데이터를 조회해 카탈로그와 대조한다. 그 결과를 드리프트 검사의 출력으로 남긴다.
드리프트가 없으면 이 질문을 닫고, 그 검사를 빌드에 넣는 것을 별도 항목으로 남긴다.
드리프트가 있으면 그것이 새 Case 가 되고, 어느 명령의 어느 속성이 어긋났는지 기록한다.
관계
- build gate라 불리는 catalog drift 검사가 어디에서도 실행되지 않는다 이 질문이 확인하려는 검사다.
- 서버 메타데이터가 명령의 정의이고 정책 파일은 허용 범위다 이 질문이 검증하려는 관계다.
- 컨테이너가 필요한 특수 레인의 실제 결과를 실행으로 확인하지 않았다 이 질문의 상위 항목이다.