apache / apache/cloudstack

Add CPU Architecture attribute to Compute Offerings to prevent architecture mismatch with Templates/ISOs

オープン
#13,593 コメント 3 件 リアクション 2 件 担当者 0 名 GitHub で見る
long-term-plan multi-arch
主要言語
Java
スター
3.1k
フォーク
1.4k
平均マージ
6日 19時間
マージ済み PR(30日)
32

説明

### The required feature described as a wish

As an Admin/Operator running a multi-arch zone (x86_64 and aarch64 hosts separated via host tags), I would like Compute Offerings to support a CPU architecture attribute, so the offering list can be filtered to match the architecture of the selected Template/ISO during deployment.

## Problem

Architecture separation currently relies entirely on host tags applied to Compute Offerings. The Template/ISO architecture selector has no relationship to Compute Offering selection — picking an aarch64 template does not filter out x86_64-tagged offerings, or vice versa. Nothing in the UI or API prevents deploying an aarch64 template on an offering tagged for x86_64 hosts, or the reverse. This surfaces as a late-stage deployment failure rather than being caught at selection time.

Note: `registerTemplate` already accepts an `arch` parameter (`x86_64` / `aarch64`), but Compute Offerings have no equivalent, so there's no architecture metadata to match against at deploy time.

## Proposed solution

- Add an optional CPU architecture field to Compute Offering create/update, consistent with the existing `arch` values used elsewhere (`x86_64` / `aarch64`).
- If unset, offering behaves as it does today — always shown, no filtering.
- If set, offering should only be selectable/listed when the chosen Template/ISO architecture matches.
- Enforce at the API level (`deployVirtualMachine`), not just the UI wizard, so direct API/Terraform/CloudMonkey usage gets the same protection.
- `listComputeOfferings` should expose the field for external tooling.
- This complements host tags (which still control placement) — the new field controls offering visibility/selectability relative to template architecture.

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

まず Compute Offering の create/update API と listComputeOfferings API から始め、次に deployVirtualMachine と既存の registerTemplate の arch パラメーターを追跡します。x86_64 と aarch64 の値がどのように一致するか、未設定の場合を含めて定義し、API、UI、Terraform、CloudMonkey の各パスで同じ動作が強制または公開されていることを確認します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
java
領域
api, cloud, infrastructure
issue の種類
機能追加
難易度
4/5
見積もり時間
3〜5日
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
48/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。