각 연결에 대한 정보 : connection_info 또는 access_info 둘 중 하나로 추진
이번 통합에서 API들의 Request/response body의 검토 및 개선이 필요
현재 : Request/response body가 같거나, JSON array 형태의 입/출력이 예상되는 API에 JSON object 단일 입/출력 형태가 존재
살펴봤을 때 source_group는
connection_info들로 구성된 그룹을 나타내고 있으며,
connection_info는 서버에 접속하기 위한 정보를 담고 있음.
(그래서 한편으로는 connection group 또는 collection group 같은 생각도 듬.)
API 구성 예시
POST /source-group
GET /source-group/{sgId}
GET /source-group
POST /source-group/{sgId}/connection_info
GET /source-group/{sgId}/connection_info/{connId}
GET /source-group/{sgId}/connection_info
GET /source-group/{sgId}/infra
향후에 그룹에 포함할 대상들이 무엇이고 목적이 어떻게 되는 지를 한번 살퍄본 후 네이밍 개선을 추진
ish-hcc
commented
1 month ago
살펴봤을 때 source_group는 connection_info들로 구성된 그룹을 나타내고 있으며, connection_info는 서버에 접속하기 위한 정보를 담고 있음. (그래서 한편으로는 connection group 또는 collection group 같은 생각도 듬.)
API 구성 예시
향후에 그룹에 포함할 대상들이 무엇이고 목적이 어떻게 되는 지를 한번 살퍄본 후 네이밍 개선을 추진
물리서버, 컨테이너, 스토리지 노드, 네트워크 노드 등
또한, 소스 컴퓨팅 인프라에 물리 서버가 1000대 있는 것을 가정해보면 두 가지 예시로 나눠 볼 수도 있음. 250대를 소스 그룹 1, 500대를 소스 그룹2, 나머지 250 대는 대상 아님 250대를 수집 그룹 1, 500대를 수집 그룹2, 나머지 250 대는 대상 아님 Ref: https://cloud-barista.github.io/cb-tumblebug-api-web/?url=https://raw.githubusercontent.[…]ta/cm-honeybee/main/server/pkg/api/rest/docs/swagger.yaml
Thanks to @yunkon-kim