Support for Tumblebug API Integration

[yunkon-kim]

What would you like to be added
: One of the proxy, gateway, or middleware to support Tumblebug(/Spider) API integration and serving.
: I'm not sure about the Spider API.

Why is this needed
: To make Beetle the representative endpoint in terms of computing infrastructure migration
: To make it efficient to communicate between subsystems

[yunkon-kim]

Spider 건 관련 Ref cloud-barista/cm-ant#10

2.2. 호출 시스템 올해 기준 spider 의 anycall api 를 직접적으로 호출하는 것으로 생각하고 있습니다. 연동의 변경이 필요한 경우 호출 엔드포인트만 변경하면 될 것 같다고 생각하기 때문에 큰 이슈는 없을 것으로 생각됩니다.

[yunkon-kim]

아래 1안), 2안) 모두에 사용할 수 있도록, proxy middleware를 개발(초기 버전)해 둔 상태 입니다. (하단 참고)

관련하여 Tumblebug API integration (wrapping) 추진을 위해 두 가지 방안을 공유드립니다. 검토해보시고 선호도, 문의사항, 의견 또는 추가적인 좋은 방안 등을 댓글로 공유해주시면 좋을 것 같습니다.

(설명이 살짝 매끄럽지 않을 수 있습니다.. 미리 양해를 구합니다.)

1안) Beetle에서 Tumblebug API 전체를 Warpping하고, Tumblebug의 API docs를 참고하도록 가이드 하는 방식

• Endpoint: Beetle의 endpoint 활용
• 서브시스템 식별자: http://localhost:8056/beetle/*, http://localhost:8056/tumblebug/*
  • 모든 tumblebug/* 요청을 Tumblebug API server로 전달
    * 메타데이터 관리: 가급적 tumblebug에서 관리함

2안) Beetle에서 Tumblebug의 필수 API(사용자가 요구하는)들을 Wrapping하고, Beetle 차원의 별도 API docs 작성 및 제공하는 방식

• Endpoint: Beetle의 endpoint 활용
• 서브시스템 식별자: http://localhost:8056/beetle/*
  • 특정 ns/* 요청을 Tumblebug API server로 전달
• 메타데이터 관리: Beetle, Tumblebug 각각에서 관리함
  • 전달 되었던 모든 요청들에 대한 응답을 중간에서 구분 및 처리 필요 by ModifyResponse

(참고)
Reverse proxy middleware (modified on 2024-08-29)

cm-beetle/pkg/api/rest/server.go

Lines 156 to 185 in fb0faaa

	// The router group for Tumblebug wrapper, which has /tumblebug as prefix
	gTumblebug := e.Group("/tumblebug")
	// Set the target server for the proxy
	target := viper.GetString("beetle.tumblebug.endpoint")
	url, err := url.Parse(target)
	if err != nil {
	e.Logger.Fatal(err)
	}
	// proxy middleware to forward the specified requests to the target server
	gTumblebug.Use(middlewares.Proxy(middlewares.ProxyConfig{
	URL: url,
	Rewrite: map[string]string{
	"/*": "/$1",
	},
	ModifyResponse: func(res *http.Response) error {
	resBytes, err := io.ReadAll(res.Body)
	if err != nil {
	return err
	}
	resBody := strings.TrimSuffix(string(resBytes), "\n")
	log.Debug().Msgf("[Proxy] response from %s", res.Request.URL)
	log.Trace().Msgf("[Proxy] response body: %s", resBody)
	res.Body = io.NopCloser(bytes.NewReader(resBytes))
	return nil
	},
	}))

기 개발 Reverse proxy middleware (초기 버전): https://github.com/cloud-barista/cm-beetle/blob/main/pkg/api/rest/middlewares/proxy.go

[yunkon-kim]

@sykim-etri (cc. @seokho-son @powerkimhub @dongjae)

시급한 건들 마무리 되시면, Kubernetes 측면에서 가볍게 살펴봐 주시면 좋을 것 같습니다. (대략적인 일정(안): 8/29(목)까지)

(예정 사항)
Beetle 내부의 의견이 모아지면, Beetle을 활용하는 서브시스템/메인테이너분들(사용자)의 의견을 수렴해 볼 예정입니다.

[seokho-son]

@yunkon-kim 1안을 선호합니다. * 메타데이터 관리: 가급적 tumblebug에서 관리함 이 시스템간 복잡성과 중복 개발 사항을 낮추는 핵심 포인트가 될 것 같습니다.

[sykim-etri]

@yunkon-kim
2안의 경우 Beetle이 Tumblebug에 너무 과한 의존성을 갖는 구성으로 보여서 여러 측면에서 취약점이 많은 방식으로 생각됩니다.

1안의 경우 Butterfly에서 Beetle과 Tumblebug의 Endpoint를 각각 사용하는 방식 대비 특별한 이점은 없을 것으로 판단됩니다. Beetle의 기능 범위를 축소하여 Beetle과 Tumblebug를 함께 사용하도록 가이드하는 방향이 여러 측면에서 바람직해 보입니다.

[yunkon-kim]

@sykim-etri 의견 감사합니다!

우선 말씀주신 의견을 3안으로 보도록 하겠습니다.

Beetle의 기능 범위를 축소하여 Beetle과 Tumblebug를 함께 사용하도록 가이드하는 방향이 여러 측면에서 바람직해 보입니다.

[seokho-son]

저는 3안도 동의합니다.

[yunkon-kim]

@seokho-son @sykim-etri

일단 2안은 Out 이네요 😃

관련해서 부연 설명을 드리고자 합니다.

개인적으로 분석해 본 바로는 목표 컴퓨팅 인프라 정보를 필요로 하는 서브시스템들이 현재 논의된 건과 관련성이 있고, 시스템 연계/활용 간에 복잡한 상황에 놓일 수 있다고 판단하였습니다.

• 직/간접적으로 관련이 있다고 판단한 서브시스템들: Grasshopper, mc-data-manager, Cicada, Ant, Butterfly

그리고, 저희는 Cloud-Barista에서 유사한 이슈를 겪었고 이에 따른 사례를 가지고 있습니다.

• Tumblebug이 Spider API들을 Wrapping하는 Forward API를 제공하는 사례(GET/READ에 한해 Forward API로 Wrapping 및 제공)

그래서, 3안을 바탕으로 API Gateway를 활용하는 것이 서브시스템간에 복잡성을 조금이라도 줄일 수 있는 시스템 형상이라는 결론에 도달했습니다. (API Gateway를 두기에는 부담이 있었습니다...)

1안 내부에 API Gateway와 유사한 역할을 하는 Proxy middleware를 품도록 만들었기에, 1안 = 3안 + API Gateway 정도로 보셔도 괜찮지 않을까 싶습니다 ^^;;

[yunkon-kim]

Beetle이 Tumblebug 업데이트에 긴밀하게 한 몸처럼 맞춰가야 하는 상황이 파악되어 공유 차원으로 답글을 남겨 놓습니다.

• Ref Align with Tumblebug v0.9.6  #115