How do we handle unverified connectionName entries when calling k8sclusterDynamic/mciDynamic APIs

[sykim-etri]

현재 k8sclusterDynamic(mciDynamic) API를 호출하기 위해서, 먼저 k8sclusterRecommendNode(mciRecommendVm) API를 호출하여 spec과 connectionName 등을 확보하고 있습니다. 그런데 connectionName이 not verified된 CSP의 리전을 대상으로 k8sclusterDynamic(mciDynamic) API를 호출하면 단순히 connection config를 찾을 수 없다는 정도의 예상치 못한 간단한 에러만 리턴하고 있기 때문에 사용자에게 혼란을 줄 수 있어 보입니다.

6:34AM ERR src/core/resource/common.go:1845 > Failed to CreateSharedResource error="Cannot find the connection config: tencent-ap-seoul"
6:34AM ERR src/core/infra/provisioning.go:1908 > Failed to create new default vNet ns01-shared-tencent-ap-seoul from tencent-ap-seoul error="Cannot find the connection config: tencent-ap-seoul"
6:34AM ERR src/core/infra/provisioning.go:2037 > Failed to get shared resources for dynamic K8sCluster creation error="Cannot find the connection config: tencent-ap-seoul"
6:34AM ERR src/api/rest/server/resource/k8scluster.go:600 > failed to create K8sCluster dynamically error="Cannot find the connection config: tencent-ap-seoul"

k8sclusterRecommendNode(mciRecommendVm) API 호출시 /connConfig와 같이 filterVerified 항목을 추가하는 등의 대응이 필요할 것으로 보입니다. 의견 부탁드립니다.

[sykim-etri]

더불어 상기 tencent-ap-seoul의 경우 다시 init.sh를 실행하니 verified로 바뀌어서 이후 진행이 가능하였습니다. connConfig별 verified 여부를 자동으로 확인할 방안도 있어야 하지 않을까 싶습니다.

[seokho-son]

@sykim-etri 현황 공유 감사합니다. 제안하시는 사항이 아래와 같은 것이 맞을까요? 1) mciRecommendVm API 호출시, 응답하는 connectionName 관련 정보에 Verified된 connection인지 여부 표기. 2) init.sh시에 connConfig별 verified 여부를 자동으로 확인.

1)의 경우, 말씀하신대로 보완이 되면 좋을 것 같습니다.

2)의 경우, 현재도 init.sh시 CSP api를 호출하여 verified 여부를 확인하게 되어 있습니다. (재실행하였을 때 verified 로 변경된 이유는 좀 살펴볼 필요가 있습니다만, 일단 CSP API 호출의 결과에 의존한 것입니다.)

[sykim-etri]

1. mciRecommendVm API 호출시, 응답하는 connectionName 관련 정보에 Verified된 connection인지 여부 표기.
2. init.sh시에 connConfig별 verified 여부를 자동으로 확인.

1)의 경우, 말씀하신대로 보완이 되면 좋을 것 같습니다.

옵션에 verified only or all(?) 등을 선택하도록 하면 API 사용자가 인식하지 않을까 싶긴 합니다.

2)의 경우, 현재도 init.sh시 CSP api를 호출하여 verified 여부를 확인하게 되어 있습니다. (재실행하였을 때 verified 로 변경된 이유는 좀 살펴볼 필요가 있습니다만, 일단 CSP API 호출의 결과에 의존한 것입니다.)

상태가 변하는 경우가 있지 않을까 싶어서 제안드린 사항이긴 합니다. init.sh 당시 네트워크 상황에 따라 not verified였지만 운영 중 verified로 변경되는 애들이 간혹 있지 않을까 하는 생각이 들어서요.. 사용자 지정 주기(ex. 하루에 한번 등)마다 갱신하는 기능이 있으면 괜찮겠다는 의견입니다. 당장은 이슈거리가 안되긴 합니다.^^

[seokho-son]

옵션에 verified only or all(?) 등을 선택하도록 하면 API 사용자가 인식하지 않을까 싶긴 합니다.

• 옵션을 제공하는 것 보다는 사용자가 API 호출 결과를 기준으로 선별해서 쓰도록 유도하면 어떨까요? (API path에 옵션을 줄이기 위함)

상태가 변하는 경우가 있지 않을까 싶어서 제안드린 사항이긴 합니다. init.sh 당시 네트워크 상황에 따라 not verified였지만 운영 중 verified로 변경되는 애들이 간혹 있지 않을까 하는 생각이 들어서요.. 사용자 지정 주기(ex. 하루에 한번 등)마다 갱신하는 기능이 있으면 괜찮겠다는 의견입니다. 당장은 이슈거리가 안되긴 합니다.^^

• 자동으로 갱신하는 방법을 예전에도 고민해본 바는 있습니다. 정책을 부여해서 반복 수행하게 만들어주는 것은 구현적으로는 크게 어렵지 않습니다.
  • 다만, 해당 방법은 CSP 크레덴셜이 크게 관련되어 있다 보니, 실제 사용자 입장에서는 결국 매뉴얼하게 검토하고 진행하도록 유도하는 것이 좋지 않을까 하는 생각이 들었습니다. 막상 구현하려고 보면, 사용자의 활용방식/유스케이스에 따라서 처리 방식이 많이 달라질 수 있을 것 같습니다. (예를 들어, 기존에 특정 CSP/리전에 만들어둔 자원이 있는데, 갱신에 의해서 활용 불가한 자원으로 변경되는 경우, 이를 어떻게 처리할 것인가) 그래서, 현재는 사용자가 필요시 갱신할 수 있도록 기본 초기화/설정 기능만 제공하고 있다고 봐주시면 좋을 것 같습니다.
  • 프로젝트 메인테이닝하는 관점에서 봤을 때도, 고민이 많이 들어가지 않은 단순 편의 기능 개발은 제한적으로 진행하는 것이 본 프로젝트 메인테이닝에 유리하다는 생각이 듭니다. 단 이 생각도 저 혼자만의 생각일 수 있습니다. 여러가지 측면을 함께 고려해주시면 좋을 것 같습니다. ^^

[seokho-son]

@sykim-etri