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.
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:
registerTemplatealready accepts anarchparameter (x86_64/aarch64), but Compute Offerings have no equivalent, so there's no architecture metadata to match against at deploy time.Proposed solution
archvalues used elsewhere (x86_64/aarch64).deployVirtualMachine), not just the UI wizard, so direct API/Terraform/CloudMonkey usage gets the same protection.listComputeOfferingsshould expose the field for external tooling.