Bug 833829 - [rhevm-webadmin] - Edit Pool shows different RAM than defined
[rhevm-webadmin] - Edit Pool shows different RAM than defined
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.1.0
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Tomas Jelinek
Tomas Dosek
virt
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-20 08:49 EDT by David Botzer
Modified: 2014-01-13 19:03 EST (History)
13 users (show)

See Also:
Fixed In Version: si15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-04 15:02:29 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Botzer 2012-06-20 08:49:19 EDT
Description of problem:
I Created a Pool of VMs with TemplateA that has 2048 RAM and changed the default RAM to 1024, I edit the Pool
in order to ADD VMs, and the RAM has returned back to default


Version-Release number of selected component (if applicable):
rhevm-engine 3.1, SI6

How reproducible:
Always

Steps to Reproduce:
1.I created a vm that works fine
2.I exported it to template (WinXP)
3.I created a new Pool of VMs (2) and the changed the default RAM per VM
4.I Run those VMs correctly
5.I edit the Pool and "Add" VMs

Actual results:
In the Pool Properties I see the default RAM

Expected results:
should show new edited RAM

Additional info:
Comment 1 Tomas Jelinek 2012-06-20 09:26:56 EDT
The problem is, that the values to the popup are filled from the template, on which the pool is based on, but it should be fill from any VM from this pool (the result of GetVmDataByPoolId query).

But I see one problem which can break this functionality. The problem is, that the VM which is a part of the pool can be edited. So, imagine, you create a pool of 2 VMs and set memory size to 2048. Than you edit one of this VMs, and set its memory to 1024. Than you open the pool dialog - it will be filled randomly from one of this two VMs to 1024 or 2048.
Comment 2 Itamar Heim 2012-06-20 09:58:05 EDT
omer - iirc, we are supposed to block edits of vms which are part of a pool?
Comment 3 Omer Frenkel 2012-07-01 07:00:14 EDT
(In reply to comment #2)
> omer - iirc, we are supposed to block edits of vms which are part of a pool?

although i agree (because it doesn't make any sense to edit a vm from pool), the engine doesn't block this, maybe we can add blocking as part of the solution to this bug
Comment 4 Einav Cohen 2012-07-01 07:52:55 EDT
(In reply to comment #2)
> omer - iirc, we are supposed to block edits of vms which are part of a pool?

- The bug is not about editing VMs within a pool; it is about the "edit pool" dialog, which is used only for adding new VMs to a pool (this dialog cannot be used to manipulate existing VMs within a pool)

- This bug sounds like a pure GUI bug, which fills the info within the dialog from the Template instead of from one of the VMs within the pool (just like Tomas has described in comment #1).
Comment 5 Barak 2012-07-04 07:27:55 EDT
The obvious solution would have been to get the info from one of the VMs in the pool, but since each VM can be edited separatly than we can not tell which VM to take the info from.

SO it looks like that a real fix will require to save the data in the pool entity, if this is the case than this BZ should be revised along with the RFE about  vm pool refactoring.
Comment 6 Greg Padgett 2012-07-09 15:37:29 EDT
From a use case perspective, it seems to me that the pool should always contain identical VMs, and that edits to the individual VMs should be blocked.  Perhaps there are use cases for overriding the configuration of individual VMs, but I can't see any where it wouldn't make sense to detach the VM from the pool before making the changes.

As a user, if I wanted to e.g. add RAM to VMs in a pool, I would expect an attempt to edit the VM to tell me to edit the pool instead, and I'd expect that editing the pool would cause the changes to take effect in each VM at the next available opportunity for each VM--i.e. when it's not running.  I know the system doesn't work like this today, but it's what I would imagine based on the (always personalized and opinion-based) "priciple of least surprise".
Comment 7 Omer Frenkel 2012-07-11 10:58:52 EDT
i agree with comment 6
editing vms which are part of pool should be blocked.
regarding updating the vm pool, i think this should be opened as an RFE
fix for UI as suggested in comment 1 should be done as fix for Bug 837693
if agreed i will move it to backend and devel_ack it.
Comment 8 David Botzer 2012-07-12 02:10:43 EDT
And if a user wants 4 VMs but there is no memory left for the fourth,
So the user will have to configure the last vm with less memory - as much as possible

This would have to be done from the vm in person

And many other examples, where the VMs in a pool have 1 or two parameters thar are not the same,

such as Domain, or number of NICs

We limit the user in many ways

-- i dont want to create a pool per change.
Comment 9 Omer Frenkel 2012-07-12 02:46:55 EDT
(In reply to comment #8)
> And many other examples, where the VMs in a pool have 1 or two parameters
> thar are not the same,
> 
> such as Domain, or number of NICs
> 

this doesn't make sense because you can't control which user get the vm with that domain or with that number of NICs, i think vm pool use case is to have pool of vms that doesn't differ from each other.
Comment 10 David Botzer 2012-07-12 02:57:24 EDT
But if I need 4 VMs and I dont have enough memory to give all 2G RAM
- System Constraints
And I am sure the fourth VM can run ok with 512M I want to be able to do so.
Comment 11 Barak 2012-07-12 05:10:17 EDT
(In reply to comment #10)
> But if I need 4 VMs and I dont have enough memory to give all 2G RAM
> - System Constraints
> And I am sure the fourth VM can run ok with 512M I want to be able to do so.

The whole idea of a pool is having identical VMs.

comments #8 & #10 are not relevant for the problem to be solved.

So it looks like we need to disable editing VMs in that belongs to a pool, and when editing the pool it is problematic to change any VM related property (e.g. RAM) as it requires handling separatly all VMs in the pool.
On the other hand editing the pool properties (e.g. description, #of VMs) should be enabled.

The only question is whether this should be done for 3.1 ?
Comment 12 Itamar Heim 2012-07-12 05:12:45 EDT
(In reply to comment #11)

> So it looks like we need to disable editing VMs in that belongs to a pool,
> and when editing the pool it is problematic to change any VM related
> property (e.g. RAM) as it requires handling separatly all VMs in the pool.
> On the other hand editing the pool properties (e.g. description, #of VMs)
> should be enabled.
> 
> The only question is whether this should be done for 3.1 ?

assuming it is a simple CanDoAction validation - yes, in 3.1 to avoid finding out people used this "feature" later and not being able to handle pools in a different way, etc.
Comment 13 Tomas Dosek 2012-07-12 05:24:14 EDT
Itamar I have only one question, don't we want to leave this editting working for manual pools?

I definitely agree on disabling RAM editing for automatic pools (there's really no sense of changing it there), but manual pool that's totally another story, isn't it?
Comment 14 Itamar Heim 2012-07-12 05:36:09 EDT
(In reply to comment #13)
> Itamar I have only one question, don't we want to leave this editting
> working for manual pools?
> 
> I definitely agree on disabling RAM editing for automatic pools (there's
> really no sense of changing it there), but manual pool that's totally
> another story, isn't it?

could be, but we don't have a mechanism to keep the pool configuration today.
once we do, we can enable this use case in a future version.
(i assume this is a simple CanDoAction and if will be needed by the field we can easily revert / allow configuring it for specific customers, but with a note their pool configuration may change on upgrade to a future version, etc.
Comment 15 Barak 2012-07-12 05:37:53 EDT
BUG 837693 - handles disabling editing of pool VMs
Comment 16 Einav Cohen 2012-07-12 06:01:18 EDT
(In reply to comment #13)
> Itamar I have only one question, don't we want to leave this editting
> working for manual pools?
> 
> I definitely agree on disabling RAM editing for automatic pools (there's
> really no sense of changing it there), but manual pool that's totally
> another story, isn't it?

no - manual pool and automatic pools are actually pretty much the same; the only difference is in the mechanism in which the VM is being returned to the pool: 

In automatic pool, a VM is returned to the pool automatically when the VM is being shut-down. In manual pool, the VM is returned to the pool when the admin decides to do so, manually.

But in any case:
- the pool VM is stateless (i.e. once it is being returned to the pool, it returns to its initial state)

- when allocating a VM from the pool to a user, there is no way of knowning which VM will be allocated; therefore, all the VMs must be identical (including in their RAM definition).
Comment 17 Einav Cohen 2012-07-12 06:02:57 EDT
Please note:

- This bug is *only* about filling the "Edit Pool" dialog correctly (i.e. according to one of the VMs in the pool instead of according to the Template from which the VMs in the pool were creatd).

- BUG 837693 (see comment #15) is about blocking editing pool VMs.
Comment 18 Itamar Heim 2012-07-12 08:54:27 EDT
(In reply to comment #10)
> But if I need 4 VMs and I dont have enough memory to give all 2G RAM
> - System Constraints
> And I am sure the fourth VM can run ok with 512M I want to be able to do so.

then you don't use pool with 2GB
Comment 19 Tomas Jelinek 2012-07-19 09:26:22 EDT
in gerrit: http://gerrit.ovirt.org/#/c/6459/
Comment 20 Tomas Jelinek 2012-07-24 07:56:58 EDT
merged: 2cdb9d3802296f229688296e973b153614171d46
Comment 22 Tomas Jelinek 2012-07-30 04:52:38 EDT
http://gerrit.ovirt.org/#/c/6638/
Comment 23 Tomas Jelinek 2012-08-06 03:59:48 EDT
merged: ee1e999da280c93f1a73e324820105f67309f23a
Comment 26 Tomas Dosek 2012-08-22 03:42:17 EDT
Verified - si15 - When creating new pool, user put options (like RAM amount, CPU cores/sockets, etc.) are applied on pool VMs instead of using options defined in template.

Note You need to log in before you can comment on or make changes to this bug.