擴充產品組合和設定

專案負責人：aaronwood@google.com 領域：建構、開發人員

問題陳述

產品組合：在 Fuchsia 平台 (fuchsia.git) 和產品專屬的存放區中，使用已建構的軟體和設定資料建立「映像檔」的程序，目前僅限於 fuchsia.git 的編譯作業。只有在完成所有軟體的編譯步驟後，才能樹狀結構內執行此操作。

產品設定在多個維度 (_eng、_eng_arrested、_user、_userdebug、LSDi 等) 中不斷增加，因此您可以為開發人員、測試人員和客戶需要的每個設定命名。

產品擁有者和開發人員仍無法輕鬆表達他們希望在任何特定時間建構/執行的組合。

這些定義大多是因為下列維度的組合擴展：

  • 將要出貨的基本產品
  • 元件版本：穩定版、最新版、開發人員版
  • 產品類型：eng、eng_arrested、userdebug、user

透過使用其他套件中元件的明確套件網址，元件拓撲本身會在裝置上的 fuchsia-pkg:// 命名空間中精煉，因為每個套件的完整網址會直接列在其父項的 cml 中：

  • root.cml
  • core.cml

如要變更用於實作某些通訊協定的元件，其他套件的內容必須變更為參照該不同套件的網址。

Fuchsia 開發人員和發布團隊必須管理樹狀結構中的所有合作夥伴產品，而樹狀結構外的產品擁有者無法依照自己的時間表發布或更新產品。這會對 Fuchsia 組織造成重大負擔，並增加與產品擁有者的摩擦。

解決方案陳述式

為解決這個問題，我們建議建立可在樹狀結構外執行的一組工具，將組合和設定的概念結合至相同程序的部分：

  • 組裝是指指定下列項目的程序：

    • 要使用的軟體元件
    • 為何彼此以這種方式相互關聯 (單一元件的拓樸)
    • 如何設定
    • 何時可以重新設定 (以及由誰重新設定)

  • 設定是指提供下列項目：

    • 每個元件需要的資料，才能正常運作
    • 產品的 CFv1 sysmgr 設定
    • 產品的整體 CFv2 拓撲
    • 核心啟動引數

這兩項作業是同一個程序的兩個部分：如何為特定產品組合及設定 Fuchsia。

為了讓 Fuchsia 的使用和設定更受控，我們建議引入「子組合」的概念。每個子組件會在拓樸結構片段中定義一組軟體和檔案，並提供設定點和值，以及明確的文件，說明組裝程序中可修改的設定。

完成後：

  • Fuchsia 平台定義了子組合，產品可使用這些子組合，在執行此樹狀結構外組合時，選擇要組合的平台行為
    • 舉例來說，軟體提交堆疊子組件包含 omaha-client (userdebug/user 版本)，而使用 system-update-checker (eng 版本) 的則不包含。
  • 客戶產品可完全在樹狀結構外組合，無須直接使用 fuchsia.git
  • 您可以使用同一組編譯軟體元件組合出多種產品變化版本。

依附元件

將客戶產品遷移至使用子組件的產品。這需要諮詢 yaar@ 和其他利害關係人，確保我們正確掌握他們的相關資訊。

將 Fuchsia 平台遷移至使用子組件的平台。這需要與各個子系統團隊進行諮詢，確保我們適當擷取正確的變化版本。

如要建立樹狀結構外映像檔，必須將特定工具 (fvm、blobfs、minfs、zbi、avbtool) 移植至可樹狀結構外使用的格式 (用於連結 Rust 的靜態程式庫，或完全移植至 Rust)。

風險與緩解措施

主要風險如下：

  • 新工具產生的輸出內容與現有工具產生的輸出內容不同

    • 因應措施：在 CI/CQ 中並行執行這兩項工具，驗證新工具是否產生相同的輸出內容，然後改用新工具。

  • 樹狀結構內和樹狀結構外工具的功能可能不同

    • 因應措施：使用樹外工具做為樹狀結構內工具，這樣我們就不必維護兩組工具。

  • 子組件結構定義設計可成為追求完美的所在。

    • 因應措施：所有結構定義都會加上版本號碼，並明確表示在程序中修訂這些結構定義，以便專注於實用解決方案，而非完美模擬系統。

  • 大量遷移作業 (產品和平台)

    • 因應措施：這項作業可分階段進行，從一組元件/標籤開始，逐步完成完整定義的子組件。
    • 緩解措施：執行計畫以謹慎的做法為主軸，避免造成過度影響。