Questions and requests based on currently public APIs

[dev4unet]

10월 17일 기준으로 Docker 이미지가 제공되지 않기에 Github 소스를 빌드해서 아래와 같은 저장소 컨셉으로 확인하면서 테스트해 봤습니다. (S/W 등은 없어서 인프라 위주로 확인했습니다.)

1. Honeybee에서 인프라 모델 정보를 조회 - GET /source_group/{{sgId}}/infra/refined/{{CSP}}/{{region}}
2. 1.번 정보를 Damselfly의 API를 이용해서 초기 입력 모델로 저장 (isinitmodel:true) - POST /onpreminfra
3. 필요한 경우 1.번이나 2.번의 모델 정보 내용을 수정해서 사용자 소스 모델로 저장 ((isinitmodel:false) - POST /onpreminfra
4. Damselfly에 저장된 모델 목록 중 원하는 소스 모델을 선택 - GET /onpreminfra
5. 선택된 모델의 정보를 Beetle의 인프라 추천의 소스 모델로 전달 - POST /recommendation/mci
6. Beetle의 응답 값을 Damselfly의 API를 이용해서 목표 모델로 저장 - POST /cloudinfra

제가 잘 못 파악하고 있지 않다면 대략적인 흐름은 위처럼 각 서브 시스템의 값들을 그대로 이용하는 형태로 생각하고 있으며 5.번 과정에서 설치된 서버에 에러가 있어서 결과 값은 확인하지 못 했지만 아래와 같은 부분이 고려되어야 할 듯싶습니다.

1. honeybee / beetle / damselfly의 소스모델 & 목표모델 포멧을 서로 통일해 주셨으면 좋겠습니다.
   honeybee와 beetle은 Docker이미지 기반으로 확인해서 포멧이 다른지 모르겠지만 규격이 살짝 안 맞네요.
   (예) honeybee의 응답과 Beetle의 입력은 "onpremiseInfraModel"로 나오는데 Damselfly의 입력 양식은 "onpreminfra"로 되어 있으며, 일부 속성들이 누락되어 있음.
2. 전체 모델 대상의 모델 목록 조회 api 필요 현재 목록 조회가 /onpreminfra와 /cloudinfra으로 각각 나뉘어 있는데 onpreminfra의 경우에는 소스모델만 저장되는 것 같고, cloudinfra의 경우에는 소스모델(IsTargetModel:false)과 목표모델(IsTargetModel:true) 모두 저장되는 것 같습니다. 현재 상태에서는 목록 api가 따로 분리되어 있어서 웹에서 소스 모델 목록을 출력할 때 /onpreminfra와 /cloudinfra api를 각각 호출해서 합쳐야하기 때문에 가급적 별도의 모델 조회 API를 하나 더 제공해주시고 해당 API에서 onpreminfra와 cloudinfra의 모델 목록을 모두 리턴 해주시면 좋을 것 같습니다.
3. Version 항목 관련 모델 규격과 상관 없는 단순히 저장된 모델에 대한 수정 이력을 사용자가 관리하기 위한 버전 항목이라면 문제는 없지만... 그렇지 않고 만약, 1.번 항목을 해결하기 위한 honeybee / beetle / damselfly 등의 각 서브 시스템들의 모델 포멧 버전을 의미한다면 honeybee / beetle 등의 서브 시스템의 모델 출력 정보에도 버전 정보가 포함되어야 할 것 같습니다. 또한, 이 경우 Damselfly의 경우 모든 버전(구버전과 신버전 등을 고려해야 하니)에 대한 포멧 정보를 보관해야 하기 때문에 내부에서 일일이 GO Struct 문법 체크를 하고 있다면 관리가 힘들지 않을까 싶기는 합니다.

개인적으로는 Damselfly에서 RAW 데이터를 전달 받아서 Model로 변환하거나 모델간 변환 등의 기능을 제공하지 않고 있으며, 소스모델과 목표모델 정보는 각 서브시스템에서 담당하고 있으니 Damselfly의 수정 및 버전 관리를 최소화 하기 위해 Damselfly는 위 시나리오처럼 단순히 DB역할을 하는 것이 어떨까 싶습니다. 즉, 모델 포멧의 경우에도 onpreminfra 등의 세부 스펙 정보를 일일이 정의하지 않고 저장 및 조회에 핵심이 되는 name / version / isinitmodel 등의 항목들을 기반으로 하고 모델 정보는 어차피 JSON 기반이므로 사용자가 전달한 내용을 그대로 Model JSON에 저장 후 필요한 경우 조회 API에서 name / version / isinitmodel 등의 항목과 모델 정보를 함께 리턴 해주면 어떨까 싶습니다.

https://github.com/cloud-barista/cloud-migrator/issues/13#issue-2506637966

[innodreamer]

@dev4unet 문의하신 내용에 대해 아래와 같이 응답을 드리고 보완이 필요한 부분은 보완하겠습니다.

• 1번의 경우,
  • "onpreminfra" -> "onpremiseInfraModel"로 request body 내부 포멧 이름을 변경하겠습니다.
  • 동일한 struct를 import 해서 사용했는데 parameter가 누락되어 있다고 하시니 확인해보겠습니다.
  • 참고) Import 해서 적용된 struct
    • onprem "github.com/cloud-barista/cm-model/infra/onprem"
    • tbmodel "github.com/cloud-barista/cb-tumblebug/src/core/model"
• 2번의 경우, 전체 사용자 모델을 조회할 수 있는 API를 추가하겠습니다.
• 3번의 경우, 오늘까지 update하여 PR 올린 버전을 기준으로 말씀드리면 version에는 아래와 같은 두가지 version이 있습니다.
  • UserModelVer : 말씀하신 것과 같이, 단순히 사용자가 사용자 모델을 update 할때 관리하는 사용자 모델의 version
  • OnPremModelVer과 CloudModelVer : (위의 1번에 언급된) import된 struct 의 tagging version을 의미하고, 사용자 모델에 적용된 OnPremModelVer과 CloudModelVer을 명시하여 특정 사용자 모델을 사용시 version을 맞춰서 사용하도록 하기 위함입니다.
  • OnPremModelVer과 CloudModelVer은 사용자가 기입하지 않고, 사용자 모델 생성시 damselfly에서 현재 지원중인 version이 자동으로 기입됩니다.
  • 추가적으로, 저희 ETRI 내부 요구 사항으로 운영중인 damselfly의 현재 지원중인 OnPremModelVer과 CloudModelVer만을 확인하는 API를 추가할 예정입니다.

[innodreamer]

@dev4unet 위의 2번에서 '소스 모델' 목록만 전체 return하면 되는지 문의드립니다.

[dev4unet]

@innodreamer 답변 감사드리며 2.번 목록의 경우 cloudinfra에는 소스 모델과 목표 모델 모두 저장되는 것으로 판단되므로 소스 모델과 목표 모델 모두 대상으로 하되 구분할 수 있는 필드와 소스 모델이나 목표 모델만 조회할 수 있도록 필터 조건이 있으면 좋을 것 같습니다. 비슷한 맥락으로 목록 결과에 onpreminfra와 cloudinfra의 모델 정보가 포함되는데 만약, 상세 정보는 각각의 onpreminfra와 cloudinfra API에서 조회해야 한다면 역시 어디서 조회해야 하는지 알 수 있도록 onpreminfra와 cloudinfra에 대한 구분 값도 함께 내려 주시면 좋을 것 같습니다.

3번 항목의 OnPremModelVer과 CloudModelVer 관련해서 문의 드립니다.

OnPremModelVer과 CloudModelVer은 사용자가 기입하지 않고, 사용자 모델 생성시 damselfly에서 현재 지원중인 version이 자동으로 기입됩니다.

라고 하셔서 살짝 혼동이 오는데 해당 버전의 경우 /source_group/{{sgId}}/infra/refined/{{CSP}}/{{region}} 처럼 모델 정보를 내려 받을 때 해당 JSON 정보에 포함되어 있나요? 아니면, damselfly에서 모델 정보를 저장할 때 자체적으로 부여하나요?

[innodreamer]

@dev4unet 3번 항목 관련하여, 사용자 모델 정보를 생성하여 저장할 때, 위의 이미지에서와 같은 형식으로 damselfly에서 현 사용하는 모델(strct, schema)의 버전을 기입하여 저장합니다.

[innodreamer]

@dev4unet 요청하신 기능으로, On-premise/Cloud의 모든 사용자 모델을 한번에 조회할 수 있는 기능을 추가시켰습니다. 소스 모델, 목표 모델을 구분하여 조회할 수 있도록했는데 구분하는 방법을 이렇게 구현하면 될지 확인 부탁드립니다. 그리고, import한 On-premise/Cloud 모델 규격 structure와 유사하게 damselfly 내의 request / response structure의 parameter들의 이름(대소문자 구분)을 변경하였으니, damselfly 코드 fetch 하신 후에 이미 저장되어 있는 damselfly DB가 있다면 초기화하고 사용하시는게 좋을거 같습니다.

[dev4unet]

@innodreamer 빠른 처리 감사합니다. /model/:isTargetModel API를 보니 전체 리스트에 각 모델의 세부 정보도 포함된 것 같아서 살펴 보니 모든 API의 list 타입이 모두 상세(Get) 정보를 포함하고 있네요^^ 다른 서브 시스템들과 방식을 통일하려고 동일한 형태로 구현하신 것 같아서 우선은 현재 상태로 검토해 보겠습니다.^^

[dev4unet]

@innodreamer 이번에 올려준 소스 기준으로 make 후 make run을 하면 아래처럼 log 오류가 발생하네요. {"level":"fatal","time":"2024-10-23T01:59:22Z","message":"Failed to create log file: open ./log/damselfly.log: no such file or directory"}

mayfly의 docker-compose 구축 및 저희쪽 테스트 환경 구축도 필요해서 가급적 Docker Hub에 Docker이미지도 올려 주시면 좋을 것 같습니다.

아래는 세부 로그 입니다.

ubuntu@ip-172-31-5-66:~/cm-damselfly$ make run
Building the binary for amd64...
Build finished!
Running the binary...
/bin/sh: 1: source: not found
find project root by using project name
2024/10/23 01:59:22 find project root by using project name
project root directory: /home/ubuntu/cm-damselfly
2024/10/23 01:59:22 project root directory: /home/ubuntu/cm-damselfly
2024/10/23 01:59:22 Key: damselfly.api.auth.enabled, Value: true
2024/10/23 01:59:22 Key: damselfly.api.allow.origins, Value: *
2024/10/23 01:59:22 Key: damselfly.api.password, Value: default
2024/10/23 01:59:22 Key: damselfly.api.username, Value: default
2024/10/23 01:59:22 Key: damselfly.autocontrol.duration_ms, Value: 10000
2024/10/23 01:59:22 Key: damselfly.root, Value: /home/ubuntu/cm-damselfly
2024/10/23 01:59:22 Key: damselfly.self.endpoint, Value: localhost:8088
2024/10/23 01:59:22 Key: damselfly.loglevel, Value: debug
2024/10/23 01:59:22 Key: damselfly.node.env, Value: development
2024/10/23 01:59:22 Key: damselfly.logfile.path, Value: ./log/damselfly.log
2024/10/23 01:59:22 Key: damselfly.logfile.maxsize, Value: 10
2024/10/23 01:59:22 Key: damselfly.logfile.compress, Value: false
2024/10/23 01:59:22 Key: damselfly.logfile.maxbackups, Value: 3
2024/10/23 01:59:22 Key: damselfly.logfile.maxage, Value: 30
2024/10/23 01:59:22 Key: damselfly.logwriter, Value: both
{"level":"fatal","time":"2024-10-23T01:59:22Z","message":"Failed to create log file: open ./log/damselfly.log: no such file or directory"}
Trying with sudo...
find project root by using project name
2024/10/23 01:59:22 find project root by using project name
project root directory: /home/ubuntu/cm-damselfly
2024/10/23 01:59:22 project root directory: /home/ubuntu/cm-damselfly
2024/10/23 01:59:22 Key: damselfly.self.endpoint, Value: localhost:8088
2024/10/23 01:59:22 Key: damselfly.node.env, Value: development
2024/10/23 01:59:22 Key: damselfly.autocontrol.duration_ms, Value: 10000
2024/10/23 01:59:22 Key: damselfly.logfile.maxsize, Value: 10
2024/10/23 01:59:22 Key: damselfly.logfile.maxbackups, Value: 3
2024/10/23 01:59:22 Key: damselfly.logfile.maxage, Value: 30
2024/10/23 01:59:22 Key: damselfly.logfile.path, Value: ./log/damselfly.log
2024/10/23 01:59:22 Key: damselfly.logfile.compress, Value: false
2024/10/23 01:59:22 Key: damselfly.loglevel, Value: debug
2024/10/23 01:59:22 Key: damselfly.root, Value: /home/ubuntu/cm-damselfly
2024/10/23 01:59:22 Key: damselfly.logwriter, Value: both
2024/10/23 01:59:22 Key: damselfly.api.auth.enabled, Value: true
2024/10/23 01:59:22 Key: damselfly.api.username, Value: default
2024/10/23 01:59:22 Key: damselfly.api.password, Value: default
2024/10/23 01:59:22 Key: damselfly.api.allow.origins, Value: *
{"level":"fatal","time":"2024-10-23T01:59:22Z","message":"Failed to create log file: open ./log/damselfly.log: no such file or directory"}
make: *** [Makefile:67: run] Error 1

[innodreamer]

@dev4unet 어제 제가 PR 올리기전 올려진 PR에서 기존 log directory와 blank log 파일이 삭제되어서 오류가 발생하네요. Logging directory가 없을때는 자동 생성되도록 보완했습니다.