Cb-tumblebug: Issue: when creating a MCIS, should a user post a cloud service provider(CSP) dependent information as parameter?

[sykim-etri]

CB-Tumblebug의 API 스펙에 따르면 MCIS 생성시 아래의 파라미터를 전달해야 합니다. 이 중 spec_id나 image_id의 경우 CSP별로 사전 생성한 후 전달하는 것으로 보입니다.

{
    "name": "aws-us-east-1-shson",
    "description": "Tumblebug MCIS Demo",
    "vm_req": [
        {
            "name": "aws-us-east-1-shson-01",
            "config_name": "aws-us-east-1",
            "spec_id": "aws-us-east-1-shson",
            "image_id": "aws-us-east-1-shson",
            "vnet_id": "aws-us-east-1-shson",
            "subnet_id": "aws-us-east-1-shson",
            "security_group_ids": [
                "aws-us-east-1-shson"
            ],
            "ssh_key_id": "aws-us-east-1-shson",
            "description": "connection_name",
            "vm_access_id": "",
            "vm_access_passwd": ""
        },
     ...
    ]
}

CB-Tumblebug의 사용자(ex. CB-Ladybug)의 관점에서 보면 결국 CSP에 의존적인 정보를 내부적으로 관리해야 하는 상황으로 보입니다. 큰틀에서 사용자가 CB-Tumblebug에 MCIS 생성 등을 요청할 때 CSP에 의존적이지 않도록 해야 할 것으로 생각합니다.

"동적 MCIR 자동 생성/삭제" 기능이 개발되면 해소될 여지가 있어 보이기도 한데, image_id 같은 부분은 쉽지 않을 것 같기도 합니다. 미리 공통 spec_id나 image_id를 CB-Tumblebug에 등록해 두고 CB-Tumblebug가 CSP별로 알아서 맵핑해주는 방법 등도 얼핏 생각나기도 한데, 혹시 관련하여 검토된 사항이 있을까요?

PS. CB-Tumblebug의 MCIS 생성 기능을 개념적으로 이해했을때는 n개의 VM을 요청하면 등록된 CSP 중 요구사항에 맞는 VM을 알아서 만든 뒤 알려주지 않을까 생각했었는데, 너무 단순하게 생각했었네요.--;

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label question to this issue, with a confidence of 0.69. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[jihoon-seo]

이 중 spec_id나 image_id의 경우 CSP별로 사전 생성한 후 전달하는 것으로 보입니다.

• image
  
  
  
  • conf.env 에, 다음과 같은 정보들을 미리 적어 놓았습니다.
  
  
  • Region aws-us-east-1 에서 사용할 cspImageId: ami-085925f297f89fce1
  
  
  • Region aws-ap-northeast-2 에서 사용할 cspImageId: ami-00379ec40a3e30f87
  
  
  • ...
  
  
  • (참고: AWS 등의 경우 똑같은 Ubuntu 18.04, 2020-09-04 버전이라도 Region에 따라 AMI ID가 다름)
  
  
  • registerImageWithId.sh: registerImageWithId API 를 사용하여 위의 정보를 TB object 로 등록하는 경우, 3가지 인자 (connectionName, name, cspImageId) 만 전달하면, TB 가 Spider를 통해 이미지 상세정보를 불러와서 TB object로 등록합니다.
  
  
  • registerImageWithInfo.sh: registerImageWithInfo API를 사용하여 위의 정보를 TB object로 등록하는 경우, TB가 Spider를 통해 이미지 상세정보를 불러오는 과정이 없으므로, 사용자가 상세정보를 제공하는 만큼 TB object로 등록합니다.
  
  
• spec
  
  
  
  • conf.env 에, 다음과 같은 정보들을 미리 적어 놓았습니다.
  
  
  • Availability Zone aws-us-east-1a 에서 사용할 cspSpecName: t2.micro
  
  
  • Availability Zone aws-ap-northeast-2a 에서 사용할 cspSpecName: t2.micro
  
  
  • ...
  
  
  • (참고: AWS 등의 경우 Availability Zone 에 따라 사용 가능한 flavor 가 다름. https://github.com/cloud-barista/cb-spider/issues/231)
  
  
  • register-spec.sh: 3가지 인자 (connectionName, name, cspSpecName) 만 전달하면, TB 가 Spider를 통해 스펙 상세정보를 불러와서 TB object로 등록합니다.
  
  

[sykim-etri]

현재 Test Suite의 image와 spec 처리에 대한 상세히 설명 달라주셔서 감사합니다.
말씀해주신 현황에 따르면 현재는 "공통" spec_id나 image_id에 대해서는 별도로 관리하고 있지 않는 것으로 판단됩니다.

추후 CSP별 spec이나 image를 추상화하고 "동적 MCIR 자동 생성/삭제"를 연계하면 훨씬 사용하기가 편할 것 같고
추가로 MCIS에 포함될 VM을 선별할 대상 CSP 범주도 사용자가 지정할 수 있도록 하면 훨씬 자유도가 높아질 것 같습니다.

[seokho-son]

@sykim-etri 질문 및 의견 감사합니다.. ^^

우선 텀블벅의 현황을 말씀드리면,
MCIR에 해당하는 자원들 (vNet, sshkey, image, spec, ..., 등) 을 CSP (클라우드 커넥션 컨피그)에 따라 직접 생성하고,
이를 활용하여 MCIS를 구성 및 생성하도록 되어 있습니다.
현황이 이런 이유는 MCIR의 경우 CSP에 의존적인 정보를 통합적으로 추상화하는 작업이 완료되지 않았기 때문입니다.
(예: 사용자가 사용하고자하는 VM의 이미지가 Ubuntu 18.04라고 하면 aws, gcp, azure 별로 사용하는 이미지의 ID가 제 각각임)

하지만, 말씀해주신 것과 같이, 텀블벅의 기본적인 방향성은, CSP에 의존적인 정보를 추상화하여,
MCIS 생성을 위해 필요한 절차 및 정보를 간소화 (추상화) 하는 것 입니다.

그에 대한 노력의 일환이 "동적 MCIR 자동 생성/삭제", MCIS 최적 배치 기능이라고 볼 수 있습니다.

텀블벅의 최적 배치 기능이 구현되면, CB-Ladybug 및 사용자가 좀 더 쉽게 MCIS를 생성하고 제어할 수 있을 것으로 보고 있습니다.
참고하시기 바라며, 추가적인 문의가 있으면 또 이슈나 코멘트 남겨주십시오.

[seokho-son]

향후 개선 사항으로 보이며, 우선 이슈는 close 하겠습니다.

[sykim-etri]

혹시 개선 사항 등에 관한 이슈들는 차후 어떻게 관리가 되는지요?