Ohara: FtpSource Connector 沒有顯示 Nodes 資訊

[vitojeng]

FtpSource Connector 沒有顯示 Nodes 資訊

• 1 個 workspace, 只有一個 pipeline.
• FtpSource Connector(A) --> Internal topic(B) --> ConsoleSink(C)
• 填入參數, 啟動成功. 等待一會兒, 出現 Metrics Panel
• 上傳 csv file, 確認 A,C 的 metrics 有正確顯示
• 發現 C 有 Nodes 資訊, 但 A 沒有.
• 觀察 Response, API(/connectors) 裡 A 的 taskStatus 是空的, C 的 taskStatus 有值

_Originally posted by @vitojeng in https://github.com/oharastream/ohara/issues/3706#issuecomment-596951869_

[vitojeng]

Log files:
worker-node1.log
worker-node2.log
worker-node3.log

[chia7712]

@@

[chia7712]

測試了一下，kafka的機制的確允許"connector"有狀態，但是task沒狀態，也就是connector啟動成功，但是task沒啟動

ping @oharastream/frontend

這可能跟UI流程有關係，因為connector的程式碼是使用者可以自訂，當出現connector有狀態但task沒狀態、或者是兩者狀態不一致(例如connector = running task=failed)的話，UI該如何顯示?

[saivirtue]

如connector = running task=failed

需要考慮這種狀況此connector還算是正常啟動(Running)嗎? 還是屬於Pending? 抑或是Failed?
這兩個的排列組合都需要考慮，而UI應該要以一個欄位(例如state)來判斷此component顯示在Pipeline上的狀態。
比較建議能夠在後端就先將狀態機的邏輯考慮進去，這樣UI比較不會有不一致的顯示方式

[vitojeng]

測試了一下，kafka的機制的確允許"connector"有狀態，但是task沒狀態，也就是connector啟動成功，但是task沒啟動

ftp source connector "task 沒啟動" 這件事有點奇怪...因為在我測試的 case 裡 , 上傳一個 csv file, 是有被處理的: metrics 有資料, 而 file 也被移動到 completed folder.

另外, 也應該不是資源的問題... csv file 很小, 而且用了四個 node 進行測試.

[chia7712]

需要考慮這種狀況此connector還算是正常啟動(Running)嗎? 還是屬於Pending? 抑或是Failed?
這兩個的排列組合都需要考慮，而UI應該要以一個欄位(例如state)來判斷此component顯示在Pipeline上的狀態。
比較建議能夠在後端就先將狀態機的邏輯考慮進去，這樣UI比較不會有不一致的顯示方式

問題就在於我們要說一部分失敗是成功還是失敗？與其去武斷地亂猜，不如把正確的狀態顯示出來

[chia7712]

ftp source connector "task 沒啟動" 這件事有點奇怪...因為在我測試的 case 裡 , 上傳一個 csv file, 是有被處理的: metrics 有資料, 而 file 也被移動到 completed folder.

你後面再丟檔案還會被移動嗎？

[chia7712]

比較建議能夠在後端就先將狀態機的邏輯考慮進去，這樣UI比較不會有不一致的顯示方式

connector的案例特殊在於，它分成兩種角色 connector and task，所以從"旁觀者"的角度來看不能100%說下斷言task failed或是狀態不一致等等能否推論出狀態=xxx。這跟其他基於containers橫向擴充的元件不一樣，例如zk, bk, wk and stream這些因為橫向擴充的設計，我們從"物理"來看可以知道有一台活著就代表服務可以持續服務。

[vitojeng]

你後面再丟檔案還會被移動嗎？

當時沒再測這部份. 剛才再重現了一次, 一樣的情況, 再丟第二個檔案.
Connector 會處理: metrics 會更新並移動檔案.

[saivirtue]

connector的案例特殊在於，它分成兩種角色 connector and task

因為UI上無法區分component之間的差異 (stream是屬於橫向擴充、connector是兩種角色)，狀態的顯示要一致才不會讓使用者誤會。
如果connector有這樣的狀況，是否我們把可以加入到Pipeline內的component都能有這樣的兩種角色?
我們可以在UI上針對這兩種不同的角色狀態來顯示，這樣未來在加入其他的component，也可以直接有一樣的邏輯

[chia7712]

如果connector有這樣的狀況，是否我們把可以加入到Pipeline內的component都能有這樣的兩種角色?
我們可以在UI上針對這兩種不同的角色狀態來顯示，這樣未來在加入其他的component，也可以直接有一樣的邏輯

你是希望API要一致吧? 如果是的話那這可以討論。反過來如果是希望架構一致的話...這就是很大的工程了 ㄎㄎ

[chia7712]

當時沒再測這部份. 剛才再重現了一次, 一樣的情況, 再丟第二個檔案.
Connector 會處理: metrics 會更新並移動檔案.

然後task依然沒有狀態?

[saivirtue]

你是希望API要一致吧? 如果是的話那這可以討論。

是的XD

[chia7712]

@saivirtue 就目前的設計來說，ConnectorInfo的狀態會有以下排列組合:

1. connector = running (第一層狀態) task = running (第二層的狀態)
2. connector = failed (第一層狀態) task == empty (第二層的狀態)

上述兩種目前的UI都已經可以處理了

1. connector = running (第一層狀態) task != running (第二層的狀態)

這一種則是我們要討論的，依照提到的API統一，或許我們就該把ConnectorInfo從

{
  "state": "running",
  "nodeName": "n0",
  "tasksStatus": [] 
}

改成

{
  "state": "running",
  "nodeNames": ["n0"],
  "tasksStatus": [] 
}

也就是第一層顯示的是"總"狀態:

• state = running 當有任何一個connectorc或task是正在跑
• nodeNames = connector + task的節點總和

另外一個跟UI有關的則是，仿效其他服務可以顯示哪些"部分"失敗，也就是把失敗的部分(tasks)顯示出來

1. connector = running (第一層狀態) task == empty (第二層的狀態)

感覺像是bug XDD 需要再測試一下。不過不管怎樣，透過上述3)的改善，至少在UI上可以顯示

[saivirtue]

看起來應該可行，但後端跟前端需要搭配修正。
可能需要另開一個issue來看其他人有沒有什麼想法

[vitojeng]

當時沒再測這部份. 剛才再重現了一次, 一樣的情況, 再丟第二個檔案.
Connector 會處理: metrics 會更新並移動檔案.

然後task依然沒有狀態?

是的. 剛才我再放了第三個檔案, 一樣會被處理. 但 API 的 Response 裡 FtpSourceConnector 的部份 tasksStatus: []

[chia7712]

是的. 剛才我再放了第三個檔案, 一樣會被處理. 但 API 的 Response 裡 FtpSourceConnector 的部份 tasksStatus: []

Could you call kafka APIs to see the status of tasks? https://docs.confluent.io/current/connect/references/restapi.html#get--connectors-(string-name)-status

[chia7712]

可能需要另開一個issue來看其他人有沒有什麼想法

4310

[vitojeng]

Could you call kafka APIs to see the status of tasks? https://docs.confluent.io/current/connect/references/restapi.html#get--connectors-(string-name)-status

Kafka connect REST API can see the status of both connector tasks.

[chia7712]

Kafka connect REST API can see the status of both connector tasks.

Could you share the response with me? thanks!

[vitojeng]

Sure

{
  "name": "fcfb6f54c-ftpsource1",
  "connector": {
    "state": "RUNNING",
    "worker_id": "vito-ohara02:42569"
  },
  "tasks": [
    {
      "id": 0,
      "state": "RUNNING",
      "worker_id": "vito-ohara02:42569"
    }
  ],
  "type": "source"
}

[chia7712]

@vitojeng could you test configurator API also? GET v0/connectors

[chia7712]

@vitojeng 可能的原因是前端會把一些舊的runtime資訊貼到"settings"，導致後端在產生response的時候會讓舊的值覆蓋到新的runtime。因此這邊我會開一個議題來將邏輯改成"settings"會被"runtime"覆蓋

FYI @wu87988622

[vitojeng]

@vitojeng could you test configurator API also? GET v0/connectors

FYI
connectors_api_response.txt

[chia7712]

@vitojeng #4312 is merged so please confirm this issue on the latest 0.9.x :)

[vitojeng]

@chia7712 The REST API looks works fine.
But UI have an issue:

Create another issue: #4332