Details
-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
False
-
False
-
None
-
HAC Infra - Sprint 222, HAC Infra - Sprint 223, HAC Infra - Sprint 224
Description
Where?
- OSD wizard -> Machine pool step.
- ROSA wizard -> Machine pool step.
- Cluster details -> Machine pools -> Add machine pool dialog.
Current behavior
UI sorts machine types,
then filters by quota and ccs_only.
Currently it tries to choose as default the first value (with possible bug: setDefaultValue() doesn't filter by ccs_only).
Expected behavior
Instead, we should take default value from /api/clusters_mgmt/v1/flavours API, specifically aws.compute_instance_type and gcp.compute_instance_type fields.
In theory, new cluster wizards should look at same flavour they're sending, and existing clusters at the cluster's flavour. Or maybe copy machine type of existing default machine pool?
In practice, OSD on red hat infra = OSD CCS = ROSA all use same flavour id osd-4 and there is no plan to split them. So can take some simplifying assumptions.
- Should we worry an old cluster might have flavour id that doesn't exist in API? I think not, can trust backend that this won't happen.
- Should we worry API's default could be a ccs_only type when creating a rhInfra cluster? etabak said not to worry, backend won't use such default.
- Do we need any fallback to previous default-is-first-visible logic? I propose not, if we choose to handle any theoretic scenarios where API's default is unsuitable, then fallback can be no default — force user to select one.
Attachments
Issue Links
- is duplicated by
-
HAC-1056 [OSD-Wizard] m5.xlarge should be selected by default in Worker node instance type
- Closed
- mentioned on