scottsignal opened a new issue, #13593:
URL: https://github.com/apache/cloudstack/issues/13593

   ### The required feature described as a wish
   
   ## 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.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to