Feature #10395: Compute Profile (oVirt) limited to 8 Cores and 16GB of memory - Foreman

Custom queries

3.10.0 release DONE
3.10.0 release TODO
3.11.0 release DONE
3.11.0 release TODO
3.8.1 release DONE
3.8.1 release TODO
3.9.2 release DONE
3.9.2 release TODO
All bugs by votes
All issues closed in the last 3 weeks
Easy and Trivial Issues
Easy Issues (only)
Foreman - new open issues in last 10 days
Good first issues - Foreman core
high prio open bugs
Host registration [open]
Mine
My issues closed in the last 3 weeks
old bugs
Open with target version set (aka blockers)
registration
taken-none
Team Atlas untriaged bugs
templates
Trivial Issues
Untriaged and opened in the past two weeks

Actions

Copy link

Feature #10395

closed

Compute Profile (oVirt) limited to 8 Cores and 16GB of memory

Added by Richard Davis almost 9 years ago. Updated almost 6 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Marek Hulán

Category:

Compute resources - oVirt

Target version:

1.13.1

Difficulty:

Triaged:

Bugzilla link:

Pull request:

https://github.com/theforeman/foreman/pull/3813

Fixed in Releases:

Found in Releases:

1.7.2

Red Hat JIRA:

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

Related issues 2 (0 open — 2 closed)

	Related to Foreman - Bug #1580: Limitiation to create only 32 GB VM	Duplicate	Marek Hulán	04/20/2012			Actions
	Related to Foreman - Bug #5901: Unable to select more than 8 cores in VMware template	Closed	Marek Hulán	05/23/2014			Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Dominic Cleal almost 9 years ago

Category changed from Compute resources - libvirt to Compute resources - oVirt

Hm yeah, hard coded. https://github.com/theforeman/foreman/blob/1.8.0/app/models/compute_resources/foreman/model/ovirt.rb#L28-L35

Actions

Copy link

Updated by Dominic Cleal over 8 years ago

Related to Bug #1580: Limitiation to create only 32 GB VM added

Actions

Copy link

Updated by Marek Hulán almost 8 years ago

Target version set to 115

Actions

Copy link

Updated by Marek Hulán almost 8 years ago

Target version changed from 115 to 1.6.3

Actions

Copy link

Updated by Marek Hulán over 7 years ago

Target version changed from 1.6.3 to 1.6.0

Actions

Copy link

Updated by The Foreman Bot over 7 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

Actions

Copy link

Updated by Marek Hulán over 7 years ago

Target version changed from 1.6.0 to 1.5.3

Actions

Copy link

Updated by Marek Hulán over 7 years ago

Status changed from Ready For Testing to Closed
% Done changed from 0 to 100

Applied in changeset 80963357e57ddfb6969b9de7e5ca4636e36b4182.

Actions

Copy link

Updated by Dominic Cleal over 7 years ago

translation missing: en.field_release set to 189

Actions

Copy link

#10

Updated by Marek Hulán over 7 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 :-)

Actions

Copy link

#11

Updated by Dominic Cleal over 7 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.

Actions

Copy link

#12

Updated by Marek Hulán over 7 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.

Actions

Copy link

#13

Updated by Dominic Cleal over 7 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.)

Actions

Copy link

#14