Bug 833829

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.

omer - iirc, we are supposed to block edits of vms which are part of a pool?

(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

(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).

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.

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".

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.

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.

(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.

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.

(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 ?

(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.

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?

(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.

BUG 837693 - handles disabling editing of pool VMs

(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).

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.

(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

in gerrit: http://gerrit.ovirt.org/#/c/6459/

merged: 2cdb9d3802296f229688296e973b153614171d46

http://gerrit.ovirt.org/#/c/6638/

merged: ee1e999da280c93f1a73e324820105f67309f23a

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.