Bug 845570 - [webadmin] new VM - pin to host settings not used from template
[webadmin] new VM - pin to host settings not used from template
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Tomas Jelinek
Lukas Svaty
virt sla
Depends On:
  Show dependency treegraph
Reported: 2012-08-03 09:19 EDT by Pavel Stehlik
Modified: 2012-12-04 15:05 EST (History)
9 users (show)

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

Attachments (Terms of Use)

  None (edit)
Comment 1 Tomas Jelinek 2012-08-06 09:49:10 EDT
in gerrit: http://gerrit.ovirt.org/#/c/6935/
Comment 2 Tomas Jelinek 2012-08-15 09:59:09 EDT
merged upstream: 32255ada9dd14be48358cc0ec524632c5fa0aca9
Comment 4 Itamar Heim 2012-08-16 07:24:11 EDT
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 08:24:20 EDT
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 08:39:48 EDT
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 08:54:35 EDT
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 10:34:28 EDT
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@redhat.com please.
Comment 9 Itamar Heim 2012-08-16 10:37:51 EDT
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 03:16:34 EDT
opened a new bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=849042
Comment 13 Oded Ramraz 2012-08-30 16:11:12 EDT
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 02:49:27 EDT
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 02:52:02 EDT
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 09:58:30 EDT
Comment 17 Tomas Jelinek 2012-09-07 03:24:26 EDT
merged upstream: 9dfa94ffbec2f732bca0ef50c3c05fc952a5a1b3

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