Feature #10395
closedCompute Profile (oVirt) limited to 8 Cores and 16GB of memory
Description
Compute Profile created using oVirt Compute Resource limits user to "8 Cores" and "16GB Memory" (available in the dropdowns) despite what's available on the oVirt/RHEV hypervisor environment.
These limits appear to be hardcoded in Foreman.
Could some extended intelligence be added to enable the user to select Core and Memory within bounds of the hypervisor environment ?
Thanks
Updated by Dominic Cleal over 9 years ago
- Category changed from Compute resources - libvirt to Compute resources - oVirt
Updated by Dominic Cleal over 8 years ago
- Related to Bug #1580: Limitiation to create only 32 GB VM added
Updated by Marek Hulán about 8 years ago
- Target version changed from 115 to 1.6.3
Updated by Marek Hulán about 8 years ago
- Target version changed from 1.6.3 to 1.6.0
Updated by The Foreman Bot almost 8 years ago
- Status changed from New to Ready For Testing
- Assignee set to Marek Hulán
- Pull request https://github.com/theforeman/foreman/pull/3813 added
Updated by Marek Hulán almost 8 years ago
- Target version changed from 1.6.0 to 1.5.3
Updated by Marek Hulán almost 8 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 80963357e57ddfb6969b9de7e5ca4636e36b4182.
Updated by Dominic Cleal almost 8 years ago
- Translation missing: en.field_release set to 189
Updated by Marek Hulán almost 8 years ago
- Translation missing: en.field_release changed from 189 to 160
Dominic, could I ask you to CP this to 1.13? It's related to #2314 and fixes the second part of the same problem, this time for CPU select field. I think it's safe, in worst case scenario if the JS that was added failed it would leave simple text field in the form. That would be still better than current 1.13 situation where select2 options are restricted to hardcoded maximum. Please reset to 1.14, if you disagree. I would fix all 1.13 related issues if that helped deciding :-)
Updated by Dominic Cleal almost 8 years ago
- Translation missing: en.field_release changed from 160 to 190
We can consider it for 1.13.1 if it appears stable, but this missed the 1.13.0 branching by a long time. It's not appropriate to add new features between RCs.
Updated by Marek Hulán almost 8 years ago
I understand we don't introduce new features after branching but this is actually a bugfix. The bug is that user can't specify number higher than N... 1.13.1 is better than nothing though.
Updated by Dominic Cleal almost 8 years ago
RCs don't generally don't introduce bug fixes for issues that aren't regressions in the RC either, they're targeted for the next bug fix release (.1) instead. The RCs are there to stabilise the changes present when it was branched, I try not to keep adding new bug fixes else it never ends.
(The exception is usually only fixes that are good enough to go into a previous branch simultaneously, i.e. 1.12-stable, so as to ensure 1.13-stable is always ahead of 1.12-stable.)
Updated by Marek Hulán almost 8 years ago
Ok, makes sense. I admit I'm biased on how safe it is to merge it :-) 1.13.1 is good (if the fix is stable enough), thanks for clarification.
Updated by Marek Hulán almost 8 years ago
- Related to Bug #5901: Unable to select more than 8 cores in VMware template added