Supports template configuration with different infrastructure providers #100
Conversation
zugwan
requested review from
Jaesang,
ktkfree,
intelliguy,
robertchoi80,
mrchypark,
seungkyua and
kyuho24
zugwan
force-pushed
the
seperate_provider_sites
branch
2 times, most recently
from
167f261 to
b571581
Compare
| @@ -88,6 +88,7 @@ spec: | |||
| templateRef: | |||
| name: manage-internal-communication | |||
| template: DeleteInternalCon | |||
| when: "{{workflow.parameters.infra_provider}} == aws" | |||
There was a problem hiding this comment.
create 는 infra_provider 와 template 이 혼합된 template_name 이라는 개념으로 사용하는데,
delete 는 infra_provider 를 사용하네요.
해당 cluster 의 infra_provider, template_name 에 대한 매핑을 TKS api 가 명확히 관리를 하고 있어야겠습니다. (UI/UX 관련없이)
There was a problem hiding this comment.
이 부분도 논의를 했어야 했는데 진행을 못했네요. 최초 클러스터 설치할 때 사용하는 템플릿의 내용을 보고 어떤 인프라 프로바이더가 사용되는지 판단해서 사용을 합니다. https://github.com/openinfradev/tks-flow/pull/100/files#diff-153f674a26da84be6ce6ef516949b8649e15dda5f38b3368918f59689672ae40R40
cluster_lcm 에서 특정 클러스터의 인프라 프로바이더 정보를 관리할 필요가 있다면 위에서 판단한 정보를 입력하는 API가 필요하고 그렇다면 lcm에서 호출할 때 인프라 프로바이더 정보까지 파라미터로 넣어줄 수 있지 않을까 해서 현재와 같이 작성되었습니다.
만약 필요가 없다면 remove-usercluster 워크플로우에서 클러스터 생성할 때 인프라 프로바이더 확인하는 방법과 유사하게 내부적으로 처리가 가능하기는 합니다. 어느 쪽으로 생각하고 계시나요?
There was a problem hiding this comment.
UI/UX 관련없이 라고했는데, UI/UX 를 위해서라도 infra_provider 와 같은 정보는 매우 중요한 정보이니 관리하는것이 맞다고 생각합니다.
어떻게 infra_provider 정보와 template_name 을 관리하는 것이 좋을지 고민되는 부분입니다. 일전에 미뤄둔 그 부분이네요.
template_name 이 고객에게 노출되는거라면 ( tks cluster create --template-name bluh~ ) 이 template_name 파싱해서라도 일단 infra_provider 관리를 해야겠습니다.
There was a problem hiding this comment.
template_name 자체에는 인프라 프로바이더 정보가 없고 내부 내용을 확인해야 합니다. CspType(https://github.com/openinfradev/tks-proto/blob/9fffe49c4625ac2bd9fbfedfe940db3cc52154f6/protos/common.proto#L82)에 byoh 를 추가하고 Cluster의 csp_id(https://github.com/openinfradev/tks-proto/blob/9fffe49c4625ac2bd9fbfedfe940db3cc52154f6/protos/common.proto#L149)를 업데이트 할 수 있는 API를 만들고 활용하는 건 어떨까요?
There was a problem hiding this comment.
네, 말씀하신 방법이 정석적인 방법입니다.
다만, 기존의 csp_type 이 contract 의 속성 정보이므로 클러스터마다 서로 다른값을 매핑하긴 어려운 부분이 있습니다. ( 물론 예전의 아키텍처일뿐 변경해야 하는 부분입니다. )
해당 부분은 다시 논의해보시죠.
project 생성부터 cluster, service 생성까지 사용자 시나리오와 함께 천천히 논의해보면 좋겠습니다.
There was a problem hiding this comment.
제가 뭔가 놓친 듯 한데, template_name 이 'aws-reference' 같은 형태로 보이는데, 프로바이더 정보가 없다는게 어떤 뜻인가요?
There was a problem hiding this comment.
제가 뭔가 놓친 듯 한데, template_name 이 'aws-reference' 같은 형태로 보이는데, 프로바이더 정보가 없다는게 어떤 뜻인가요?
저희가 개발, 테스트 등 내부 검증을 위해 사용하는 표준 형상에는 편의 상 프로바이더 정보가 들어가겠지만 사용자가 작성해서 사용할 템플릿 이름, 그리고 클러스터 이름에는 인프라 프로바이더 정보가 포함될거라는 보장이 없다는 의미입니다.
There was a problem hiding this comment.
이 부분도 논의를 했어야 했는데 진행을 못했네요. 최초 클러스터 설치할 때 사용하는 템플릿의 내용을 보고 어떤 인프라 프로바이더가 사용되는지 판단해서 사용을 합니다. https://github.com/openinfradev/tks-flow/pull/100/files#diff-153f674a26da84be6ce6ef516949b8649e15dda5f38b3368918f59689672ae40R40
cluster_lcm 에서 특정 클러스터의 인프라 프로바이더 정보를 관리할 필요가 있다면 위에서 판단한 정보를 입력하는 API가 필요하고 그렇다면 lcm에서 호출할 때 인프라 프로바이더 정보까지 파라미터로 넣어줄 수 있지 않을까 해서 현재와 같이 작성되었습니다. 만약 필요가 없다면 remove-usercluster 워크플로우에서 클러스터 생성할 때 인프라 프로바이더 확인하는 방법과 유사하게 내부적으로 처리가 가능하기는 합니다. 어느 쪽으로 생각하고 계시나요?
LCM에서 프로바이더 관리를 한다면, 애초에 workflow 호출 전에 이미 프로바이더 정보를 인식해서 가지고 있을 수도 있겠군요. 그럼 클러스터 생성 시와 삭제 시 일관적인 인터페이스로 진행하는 것이 가능할 수도 있겠습니다.
There was a problem hiding this comment.
제가 뭔가 놓친 듯 한데, template_name 이 'aws-reference' 같은 형태로 보이는데, 프로바이더 정보가 없다는게 어떤 뜻인가요?
저희가 개발, 테스트 등 내부 검증을 위해 사용하는 표준 형상에는 편의 상 프로바이더 정보가 들어가겠지만 사용자가 작성해서 사용할 템플릿 이름, 그리고 클러스터 이름에는 인프라 프로바이더 정보가 포함될거라는 보장이 없다는 의미입니다.
네, 템플릿 명이 아니라 포함된 디렉토리명으로 판단하는 거였네요. 이해했습니다.
zugwan
force-pushed
the
seperate_provider_sites
branch
4 times, most recently
from
d4beee7 to
7ff9d12
Compare
This commit will be reverted when '--template' parameter is added to 'tks cluster create' command
zugwan
force-pushed
the
seperate_provider_sites
branch
from
7ff9d12 to
7c2e4ad
Compare
This commit is reverted if TKS cluster LCM service maintains the cluster's infra provider information and can call remove cluster workflow using that infra provider information.
zugwan
force-pushed
the
seperate_provider_sites
branch
from
7c2e4ad to
543e6cd
Compare
|
|
||
| echo $CLUSTER_INFO | ||
|
|
||
| ## Replace site-values with fetched params ## | ||
| sed -i "s/clusterName:\ cluster.local/clusterName:\ $CLUSTER_ID/g" $CLUSTER_ID/$CLUSTER_ID/tks-cluster-common/site-values.yaml | ||
| sed -i "s/clusterName:\ cluster.local/clusterName:\ $CLUSTER_NAME/g" $CLUSTER_ID/$CLUSTER_ID/tks-cluster-common/site-values.yaml |
There was a problem hiding this comment.
이 PR 에 대한 내용은 아닙니다.
clusterName 이
. 고객이 생성할때 입력하는 휴먼리더블 이름
. 지금 여기서 사용하는 프리픽스된 clusterId
. 어떤 곳에서는 full clusterId 사용
로 다양하게 사용되는것 같아 오개발할 위험성이 있어 보입니다.
애초에 ClusterId 를 생성하는 주체는 tks시스템이므로 발급시 unique 함만 보장하면 될 것 같습니다.
clusterId, contractId 등을 uuid 가 아닌 unique 가 보장되는 "8자리 uuid" 를 clusterId 로 사용하면 어떨까요? 위험한 생각일까요?
정리하면
. clusterName : 고객이 입력하는 human-readable 이름
. clusterId : 8자리 Cprefixed_uuid (유니크가 보장되는)
There was a problem hiding this comment.
저도 일단 기록을 남기는 용도로 기억을 더듬어 보면 clusterName은 human-readable 한 것 외에는 실제 TKS에서 다른 용도로 사용하지 않는 값으로 정의를 했었고 clusterId로 모두 관리하자는 게 의도였습니다. ID 형식을 무엇으로 할 것인가 얘기가 나왔을 때에는 uuid가 가장 무난하기 때문에 선정이 되었습니다.
|
어차피 향후 LCM 등과 연동되면 전체적인 흐름을 다시 한번 점검하게 될테니, 이 정도로 merge하고 잘 F/U 하면 될것 같습니다. |
|
근데 머지하려고 봤더니 lint 에러가 하나 있네요. (다른 파일에 정의된) Workflow 레벨의 output을 인지하지 못해서 발생하는 에러인 것 같긴 합니다. |
template lint 가 CICD 클러스터 대상으로 수행하는 것인데 create-usercluster에서 호출하는 create-cluster-repo를 수정한 버전이 아닌 현재 클러스터에 적용된 내용으로 참조해서 실행하기 때문에 에러가 발생하는 것으로 보입니다. 테스트용 환경에서는 아래와 같이 오류가 발생하지 않습니다. |
템플릿 사이트의 인프라 프로바이더 그룹 (tks-cluster-aws or tks-cluster-byoh) 디렉토리를 기준으로 인프라 프로바이더 정보를 얻어서 이후 클러스터 설치 과정에서 사용하도록 하였습니다.
TKS cli는 'template-std' 라는 템플릿 명을 하드코딩 되어 사용하기 있기 때문에 aws, byoh 인프라 프로바이더를 임시적으로 선택해서 설치하기 위해서 a609f1c 를 추가하였고 TKS cli에서 클러스터 생성 명령어
tks create cluster에 템플릿 지정 플래그가 추가되면 되돌리도록 하겠습니다.추가 반영한 내용이 있어 업데이트합니다 (2022/06/29)
생성되는 클러스터의 인프라 프로바이더 변경을 위해서
tks create cluster실행 전 다음 값을 먼저 변경해야 합니다.remove-usercluster-wftpl.yaml: infra_provider 파라미터 기본 값 변경 (aws or byoh)