Bug 845570 - [webadmin] new VM - pin to host settings not used from template
Summary: [webadmin] new VM - pin to host settings not used from template
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.0.5
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
: ---
Assignee: Tomas Jelinek
QA Contact: Lukas Svaty
URL:
Whiteboard: virt sla
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-03 13:19 UTC by Pavel Stehlik
Modified: 2012-12-04 20:05 UTC (History)
9 users (show)

Fixed In Version: si18
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-04 20:05:08 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Comment 1 Tomas Jelinek 2012-08-06 13:49:10 UTC
in gerrit: http://gerrit.ovirt.org/#/c/6935/

Comment 2 Tomas Jelinek 2012-08-15 13:59:09 UTC
merged upstream: 32255ada9dd14be48358cc0ec524632c5fa0aca9

Comment 4 Itamar Heim 2012-08-16 11:24:11 UTC
how does this behave for power user portal, considering we don't allow these fields for users at all?

Comment 5 Tomas Jelinek 2012-08-16 12:24:20 UTC
On the template change, it sets up all the properties of the host pinning as in web admin, just it is not visible to the user. On the save, it sends this values to the server.
So, basically the same way as in web admin, just the user can not adjust it, because it is invisible for him.

Is this correct?

Anyhow, as I have checked it now I have found a different bug in this combination. The host list is not filled in the user portal, so when the "specific" is selected on a template on which this VM is based on, the validation of the host fails and the VM can not be created.

So, what is the correct behavior? Should the user portal set the host pinning properties from the template or not?

Comment 6 Itamar Heim 2012-08-16 12:39:48 UTC
you should not copy these fields in the user portal - users are not allowed to fill them.
i thought we (well, you[1]) also removed these fields from VM (maybe we forgot to remove them from template/pool?)

[1] see bug 839230

Comment 7 Tomas Jelinek 2012-08-16 12:54:35 UTC
The bug 839230 just hides the "Host" side tab in the dialogs to disable to the user to directly edit them. But when in the webadmin this values are set, the userportal edit will send them to the server again.

Should I open a bug which will remove also this functionality?

Comment 8 Itamar Heim 2012-08-16 14:34:28 UTC
they should not be visible to the user.
user portal should send them as-is.
if they are not changed, the action should not fail.
user should fail if they try to change these (so user portal accepting and sending them back as-is should not fail).

if the fields aren't visible to user at all, and just a backend logic, either try to fix, or assign to oourfali please.

Comment 9 Itamar Heim 2012-08-16 14:37:51 UTC
but please note that creating a new VM from power user portal should not take these fields from the template, since that would be setting them by the user as part of creating the VM which is not allowed.

Comment 10 Tomas Jelinek 2012-08-17 07:16:34 UTC
opened a new bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=849042

Comment 13 Oded Ramraz 2012-08-30 20:11:12 UTC
I created a VM and set it to run on a specific host .
After creating template from it and editing the template , i see that run on any host in the cluster is checked . 
Reopen this issue .
Tested with si16

Comment 14 Tomas Jelinek 2012-08-31 06:49:27 UTC
well, but this is a different case: this bug report was about creating a VM from a pool, not creating a pool from a VM. But I understand that they are related, so I hope it will be OK to fix also this issue under this bug.

Comment 15 Tomas Jelinek 2012-08-31 06:52:02 UTC
ahh, please ignore my previous comment. I wanted to say:
The original bug report was about creating a VM from a template and not creating a template from a VM. But yes, I will fix also this new bug as a part of this one since they are related.

Comment 16 Tomas Jelinek 2012-09-06 13:58:30 UTC
http://gerrit.ovirt.org/#/c/7822

Comment 17 Tomas Jelinek 2012-09-07 07:24:26 UTC
merged upstream: 9dfa94ffbec2f732bca0ef50c3c05fc952a5a1b3


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