파일 저장소
storage 묶음의 오퍼레이션 3 개입니다.
| 메서드 | 경로 | 하는 일 |
|---|---|---|
| GET | /v1/orgs/{orgSlug}/projects/{projectName}/storage | 오브젝트 스토리지 상태 (runlot storage usage) |
| POST | /v1/orgs/{orgSlug}/projects/{projectName}/storage | 스토리지를 부여한다 (runlot storage create) |
| DELETE | /v1/orgs/{orgSlug}/projects/{projectName}/storage | 부여를 뗀다 (runlot storage delete) |
GET /v1/orgs/{orgSlug}/projects/{projectName}/storage
부여 여부·접두·쿼터·사용량 (docs/storage.md §7·§8). usedBytes 는
노드가 보고한 마지막 관측값이라 주기만큼 늦다 — 그 사이에 쿼터를
조금 넘길 수 있다.
객체 목록과 서명 URL 은 이 표면에 없다. 자격이 node-agent 에만 있고 (§4.1), 바이트를 CP 로 두 번 나르지 않는 것이 §5 의 판단이다.
viewer 이상.
operationId getStorage
| 응답 | 뜻 | 본문 |
|---|---|---|
| 200 | 스토리지 상태 | StorageStatus |
| 403 | — | — |
| 404 | — | — |
| 503 | no_core — cp-core 연결이 없다 | Error |
POST /v1/orgs/{orgSlug}/projects/{projectName}/storage
멱등이다 — 두 번 불러도 접두는 그대로다. 재시도가 접두를 바꾸면 이미 그 접두 아래 앉은 객체가 통째로 안 보이게 되고, 그 손실은 조용하다.
요청 본문이 없다. 접두는 격리의 경계이고 (docs/storage.md §4.4) 쿼터는 요금제가 정하므로 (§4.5), 둘 다 사용자가 정하는 값이 아니다.
부여가 서면 노드가 다음 수렴에서 워커에 env.storage 를 붙인다 —
재배포는 필요 없다 (env.db 와 같은 길).
member 이상. 감사 storage.grant.
operationId grantStorage
| 응답 | 뜻 | 본문 |
|---|---|---|
| 200 | 부여 상태 (이미 있었으면 기존 값) | StorageStatus |
| 403 | — | — |
| 404 | — | — |
| 503 | no_core | Error |
DELETE /v1/orgs/{orgSlug}/projects/{projectName}/storage
객체는 지워지지 않는다. 접두 아래를 지우는 것은 op_id 로 멱등한
CP 오퍼레이션이어야 하고 (docs/storage.md §7, 데이터베이스 삭제와 같은
레인) 그 레인이 아직 없다 — 그 사실이 감사에 남는다.
해제도 멱등이다: 없는 부여를 떼는 것도 204 다.
admin 이상 — 요금은 멈추지만 객체가 고아가 되므로 배포를 되돌리는 것과
같은 칸에 두지 않는다. 감사 storage.revoke.
operationId revokeStorage
| 응답 | 뜻 | 본문 |
|---|---|---|
| 204 | 뗐다 | — |
| 403 | — | — |
| 404 | — | — |
| 503 | no_core | Error |