API-related enhancement requests #37
Comments
|
|
@dev4unet @ish-hcc (cc. @powerkimhub @innodreamer) 안녕하세요. 생각을 맞추기 위한 차원에서 4번과 관련하여 의견을 말씀드립니다. 현재 인프라 모델 정보는 OnPremInfra로 통일되어 있습니다.
각 서브시스템에서 이를 활용해서 API 들을 제공하고 있는데요. 관련하여, 개선(안), 의견, 우려, 대안 등이 있으시면 편하게 답글 남겨주시기 바랍니다. |
|
구체적인 사항에서 협의할 내용이 있을지 몰라 구현을 중심의 부연 설명을 드립니다. 살펴보시고, Portal/사용자 관점에서 필요하신 부분들을 말씀해주시면 좋을 것 같습니다. 먼저, 관련 서브시스템 간에 API 에 OnPremInfra 모델이 반영된 현황 입니다. Honeybee 컴퓨팅 인프라 소스 모델 조회 API Damselfly 컴퓨팅 인프라 소스 사용자 모델 등록 API
Beetle 목표 클라우드 인프라 추천 API
다음으로, Honeybee의 범위와 API에 CSP, Region 정보 포함의 필요 여부 관련 사항입니다.
Beetle의 목표 클라우드 인프라 추천 API의 Provider, Region 관련
|
|
@yunkon-kim |
|
@ish-hcc @yunkon-kim 간단한 내용인데 테스트 후 글로 다시 자세히 쓰려니 답변이 좀 늦었습니다. 예를 들어, Honeybee로부터 인프라 소스 모델 정보를 얻어서 아무런 수정 없이도 Beetle의 인프라 추천 모델 요청의 입력으로 그대로 전달했을 때 동작에 무리가 없어야 하지 않나 싶습니다. 하지만, 현재는 받은 정보를 그대로 사용하지 못하고 각 시스템의 요청에 맞도록 모델 포멧을 가공하는 추가 작업이 필수로 발생합니다. 그리고 단일 서버 정보를 조회하는 경우 응답이 아래와 같습니다. 하지만 Beetle의 입력 정보는 아래처럼 전달해야 합니다. 즉, Beetle의 경우 필수 소스모델 JSON 정보는 아래처럼 생겼습니다. 그렇다면 개인적으로 봤을 때 인프라 소스 모델 포멧은 onpremiseInfraModel항목을 포함한 하위 항목이지 않나 싶습니다. 현재는 각 서브 시스템들이 위처럼 응답 및 입력을 요청하는 상황인데
위처럼 Honeybee에서 주는 정보와 Beetle이 원하는 입력 모델의 차이를 Damselfly에서 처리해주나 싶었지만 Damselfly도 완성된 모델 정보를 입력으로 받고 있기 때문에 현재는 고스란히 시스템을 이용하는 이용자까지 모델 포멧에 강제로 관여해야만 합니다. **개인적으로는 그룹 단위로 인프라 소스 모델 정보를 요청하든 특정 서버에 대한 인프라 소스 모델 정보를 요청하든 모두 마이그레이션을 위한 인프라 소스 모델에 대한 요청이니 지금처럼 인프라 소스 모델에 활용할 수 있는 형태의 정보가 아니라 onpremiseInfraModel요소를 포함한 인프라 소스 모델로 나와야 하지 않을까 생각됩니다. 그 외 특정 시스템에서 로직 처리를 위해 필요한 추가 정보들은 해당 기능을 수행하기 위해 모델 외의 부가 정보로 전달 받아서 처리해야한다고 생각합니다. 그래야 사용자는 향후 추가되거나 변경될 모델 포멧에 대해서 신경 쓰지 않고 마이그레이션 하려는 대상이 온프라미스인지 클라우드인지 등에 구애 받지 않고 담당 시스템의 응답으로 받은 모델 정보에서 필요한 항목의 값만 수정하면서 편하게 이용할 수 있지 않을까 싶습니다. 그렇지 않다면 두 시스템을 이용하려는 사용자는 두 시스템의 연동을 위해 각각의 목적에 맞게 특정 버전의 모델 포멧에 대해서 매번 작업을 해야 하며 포멧이 변경되면 매번 수정이 발생 할 수 있으리라 생각됩니다. 현재 인프라 소스 모델만 놓고 보면 Honeybee의 /source_group/{{sgId}}/infra/refined/{{CSP}}/{{region}} API의 응답만이 Beetle이 원하는 onpremiseInfraModel 정보를 포함한 인프라 소스 모델 형태로 리턴되고 있습니다. 위 형태가 저희가 필요한 형태인데 위 API의 CSP와 Region정보를 포함해서 요청하는 것은 저희 쪽에서는 맞지 않기에... |
|
@dev4unet @ish-hcc @innodreamer (cc. @powerkimhub ) 자세히 설명해주셔서 감사합니다! 서브시스템들이 안정화 되지 못한 상태에서 다양한 서브시스템의 API를 활용하시는 과정에서 Request/response body의 차이로 인해 어려움을 겪으시는 것 같습니다. 모델을 다루는 방식의 차이로 인한 이슈도 이해되는 부분이 있습니다. 우선, 설명해 주신 내용을 바탕으로 추진 방향을 공유 드려보고자 합니다. 1. 다양한 모델의 확장성을 고려하여 "모델이름:모델"로 스키마 개선 "onpremiseInfraModel": {
"network": {},
"servers": []
}(Schema) "xxxModel": {
"xxx": {},
"xxx": []
}이를 위해, cm-model에서 개선 후, 서브시스템에서 반영해 주시면 될 것 같습니다. 2. 1번을 반영하시면서, 아래 Honeybee API들의 출력에 대한 의견을 검토해 보신 후, 의견 공유 또는 개선 해주시면 될 것 같습니다.
3. 2번이 이후에, Damselfly에 개선된 모델을 반영해 주시기 바랍니다. 추가로, 생각이 다른 부분이 있어 공유드립니다. 진행하면서 의견을 맞춰가면 좋을 것 같습니다.
마지막으로, 여전히 모델에 대한 견해 차가 있고, 다양한 모델이 추가될 것이므로 |
|
업데이트 현황 공유드립니다.
Honeybee, Damselfly 개선 및 테스트 완료 후, Honeybee, Damselfly, Beetle를 같이 릴리스 찍으면 될 것 같습니다. |
1. 모델 차이 개선
두 API에 대해서는 /source_group/{{sgId}}/infra/refined 에 맞추는 것으로 하겠습니다. /source_group/{{sgId}}/connection_info/{{connId}}/infra/refined 를 조회하여도 2. Beetle에서 Recommend 인프라를 제공하기 위한 Requst 관련
3. 임시 API 삭제사전에 말씀드린 것처럼 이제 /source_group/{{sgId}}/infra/refined/{{CSP}}/{{region}} API는 삭제하여 더이상 제공 되지 않습니다. 그 외에는 cm-model에 제시하여 주신대로 cm-honeybee에서의 모델 통일 작업을 하여 추진하는 방향으로 하겠습니다. |
|
@ish-hcc @yunkon-kim 세부적인 것은 좀 더 확인해 봐야겠지만 잠깐 API 위주로 테스트해 봤을 때 현재 honeybee, beetle, damselfly 모두 아래 형태로 통일된 것 같습니다.^^ 참고로, 아래부터의 내용은 단순한 부연 설명겸 의견입니다. Honeybee와 Beetle의 온프레미스 인프라 마이그레이션을 예를 들어 구체적으로 설명을 드리면,
정답은 없기에 Honeybee에서 onpremiseInfraModel 이름이 포함된 구조를 반드시 리턴해야 할 필요는 없겠지만 개인적으로는 위처럼 연계된 시스템간의 규격은 해당 시스템들만 사용하는 별도의 규격으로 정해서 값 수정을 제외한 변경은 사용자의 간섭으로부터 격리 시키고, 개별 시스템에서 추가로 필요한 부가 정보를 별도로 받는 형태로 분리되는 방식이 조금 더 유연하게 처리가 가능하지 않을까 싶습니다. 즉, API를 이용하는 입장에서는 두 시스템의 의존성이 높은 모델 규격에 대해서는 독립된 변수처럼 별도의 스키마로 정의되고 필요한 정보들은 해당 스키마와 무관하게 전달 받아서 onpremiseInfraModel 부분의 명칭이 onpremiseInfra로 바뀌든 onpremiseInfraModel 내부에 버전 제도가 도입되어서 버전 간의 상호 호환성을 유지하든 honeybee와 beetle을 이용하는 사용자는 적어도 두 시스템에만 의존 관계가 있는 부분에 대해서는 최대한 신경 쓸 필요가 없고 다른 시스템들의 API도 비슷한 방식으로 제공하는 방향이 좋지 않을까 생각해 봅니다. |
|
@ish-hcc 최신 버전으로 테스트해 봤는데 Coonnection 정보의 Port가 암호화 되어서 조회되고 있습니다. |
|
엄청난 글을 작성해주셨네요;; 혹시나 잘못 이해하는 부분이 있을까 하여 몇 차례 읽어 보았습니다. 그런데, 아직 생각이 다른 부분이 있다고 느껴져 의견을 말씀드립니다. 현재 제 생각으로는, _사용자(Admin)_가 서브시스템의 API docs를 살펴본 후, 이를 사용하는 Actor는 아니라고 생각합니다. _사용자(Admin)_는 만들어진 Cloud-Migrator Platform WebConsole을 이용해서 마이그레이션을 수행하게 될 것이라고 생각합니다. (물론 이에 대해 정해진 바는 없습니다.) 한편, 서브시스템 API docs에서 API 규격을 파악한 후, 이를 활용하는 Actor는 _개발자_라고 생각됩니다. 예를 들어, Platform을 개발하고 있는 우리 Maintainer/Contributor 분들이 될 수 있겠습니다. 그렇기에, 빠르게 맞춰드리는 것이 좋겠다고 판단하였고, 바로 "모델명:모델"로 스키마를 변경해드린 상태 입니다. 다만, "모델명:모델"이 Honeybee와 Beetle 등의 서브시스템 API의 속성 값으로 들어갈 수 있으나, API간 입출력이 동일할 수 없을 것이라는 의견을 드렸던 것 입니다. 설명해 주신 내용을 제가 잘 이해했다면 API간 입출력 자체가 동일하지 않다는 것은 합의점을 찾은 것 같습니다. ( 1번 관련) 다른 서브시스템에 영향이 가지 않으면 좋겠다는 의견을 주셨기에 당분간 새로운 모델을 정의 시 "모델명:모델"으로 맞춰서 제공해드리는 방향으로 진행하겠습니다. 다만, "모델"만 제공하는 것과, "모델명:모델"로 제공하는 것이 다른 시스템에 주는 영향이 그다지 크지 않을 것으로 판단되며, "모델명"이 명시된다면 이로 인한 강결합성을 갖게되고, 모든 서브시스템간에 동기화를 강제하는 부분이될 것 입니다. 또한, 모델이 세분화 되거나 다양한 형태로 제공되기 시작했을 때, 상위 서브시스템에서 구분 및 Handling 해야할 API/모델이 늘어나게 될 것으로 예상해 볼 수 있습니다. 모델이 하나인 지금은 이대로 추진하고요. 추후 모델이 늘어났을 때 현황 및 방안을 공유드리겠습니다. 소스 모델의 개발 및 적용 순서를 설명 드립니다. 참고하시면 될 것 같습니다. ( 2번 관련) 위에서 말씀드린 사용자에 대한 견해 차이로 설명을 대신하도록 하겠습니다. (3번 관련) 실제 대상을 분석하여 모델을 도출하는 것을 가정하면, [타입 2]가 더 적절하다는 것에 동의합니다. 마지막으로, 모델은 Honeybee, Beetle 이외에도 여러 시스템에 연관되기 때문에 관련된 모든 서브시스템에 동기화가 필요할 것으로 보이네요. 관련되는 서브시스템들은 아래 링크의 "통합 주요 기능 및 관계도"를 참고하시면 될 것 같습니다. |
|
Port 정보 정상적으로 복호화된 것 확인했습니다. |
일부 API들에 대해서 관리자가 사용하는 Web UI 구현 시 고려 및 개선되었으면 싶은 기능들이 있어서 검토 요청 드립니다.
Connection 정보에서 Port는 암호화 대상에서 제외 하기
조회된 Connection 정보의 ID & Password & Privatekey 복호화 방법
or 복호화를 위해 제공되는 API가 있나요?
Connection 정보 수정 시 암호화에 따른 이슈
모델 정보 통일 관련
{{baseUrl}}/source_group/{{sgId}}/connection_info/{{connId}}/infra/refined
{{baseUrl}}/source_group/{{sgId}}/infra/refined
{{baseUrl}}/source_group/{{sgId}}/infra/refined/{{CSP}}/{{region}}
Connection 정보에 CollectedDatetime 정보 포함
The text was updated successfully, but these errors were encountered: