Bug 1293154

This is a side effect of having template versions.
If you select the base-version of the template, this template will always be used.
If you select the "latest" then if the VM is set to be stateless, it will be updated to the latest version of the template on each run.
We can argue about this design, but it is essential to have both options in the list so the user will be able to select the one he needs.

I think we should filter out the duplicity when there is only one - latest - version

(In reply to Michal Skrivanek from comment #3)
> I think we should filter out the duplicity when there is only one - latest -
> version

Let's say that I have a template with no sub-versions and I want to create a VM that will be updated to the last sub-version that *will* be created for the template, how would I be able to specify it?

(In reply to Arik from comment #4)
Possible solution is to revert the change that combined the template and its sub-version selection to one list. In 3.5 we have two drop-down lists - one for the template and once you select a template the second list of sub-versions gets updated according to the selected template.

Arik, I agree that two drop-down lists were more usable.

Alternatively, if the main use is for stateless VMs (the template cannot be changed later for stateful VMs, right?), can the filtering mentioned in comment #3 be done only if 'stateless VM' checkbox is not checked?

(In reply to Petr Spacek from comment #6)
> Arik, I agree that two drop-down lists were more usable.
> 
> Alternatively, if the main use is for stateless VMs (the template cannot be
> changed later for stateful VMs, right?)

Right

>, can the filtering mentioned in
> comment #3 be done only if 'stateless VM' checkbox is not checked?

Yeah but then it would be weird from user experience perspective
I assume that people fill the dialog from top to down (that's the tab order as well). by default the VM is not stateless - so the user will not be able to select the latest (since it will  be filtered) and only when after he reaches the stateless checkbox he will need to go to the template and change it to the latest (assuming he wants the latest version of some template).

I think that the nicest solution would be that next to the templates will be a checkbox of "use latest" - if it is checked then only base templates would be presented in the list, otherwise all base templates and their sub-versions (excluding the 'latest' versions) would be presented. In addition next to the 'use latest' checkbox we should warn the user that it has no meaning for stateful VM

Hmm, when I read your latest proposal, I still think that the original behavior with two drop-down lists was cleanes and easiest to use. Could we revert back to it?

we can't make the top part any longer as it's static. checkbox sounds the only acceptable one:/ (also ruled out expanding the subversions dropbox to the left...looks too ugly)

(In reply to Arik from comment #7)

> I assume that people fill the dialog from top to down (that's the tab order
> as well). by default the VM is not stateless - so the user will not be able
> to select the latest (since it will  be filtered) and only when after he
> reaches the stateless checkbox he will need to go to the template and change
> it to the latest (assuming he wants the latest version of some template).

it is on the same tab though, so it's not that "far away". It might be alright to reload/refresh the templates info when you check/uncheck "Stateless"
Preferably by default show "name" when there is only one version, "name (x)" when there are x>1 versions. When "Stateless" is checked show both "latest"(perhaps in bold) and individual versions

all the other alternatives looks ugly:/

actually, we're talking about Pools mostly, and there the layout looks a bit different. The former subversion field is still separated there (Tomas?;-) and we can use that space to convey the functionality of "latest" vs "specific version" to users.
And in the New/Edit VM dialog we can implement comment #10 (for a not-so-common use case of custom stateless VMs using "latest")

(just so it's not lost in all the comments - we want to make the drop-down list larger as well;-)

(In reply to Michal Skrivanek from comment #11)
> actually, we're talking about Pools mostly, and there the layout looks a bit
> different. The former subversion field is still separated there (Tomas?;-)

it is not separated - it may look like it because of this bug :) https://bugzilla.redhat.com/1302372

Failed QE:

tested on rhevm-3.6.5-0.1.el6.noarch.
Steps:

1. Create new VM -> General tab -> verify that template drop-down list present each version per template without the "latest" template option (stateless check-box unchecked by default). --- PASS

2. check the stateless checkbox -> verify that the template drop-down list present each version per template + the "latest" template option -- PASS

3. stateless checkbox is checked -> choose a template from the drop-down list (could be latest, could be any other version as well) --- ERROR: 
upon choosing a template, the vm configuration is refreshed and the stateless checkbox is again unchecked. Template drop-down behaves as not stateless case. If the "latest" template was chosen then in addition to the unchecked stateless box, the template will be set to Blank   |   base version(1).

So the end result is that there's no possible way to create a stateless vm and change the template through the webadmin.

> 3. stateless checkbox is checked -> choose a template from the drop-down
> list (could be latest, could be any other version as well) --- ERROR: 
> upon choosing a template, the vm configuration is refreshed and the
> stateless checkbox is again unchecked. Template drop-down behaves as not
> stateless case. If the "latest" template was chosen then in addition to the
> unchecked stateless box, the template will be set to Blank   |   base
> version(1).

This depends on if the "latest" template or the one you have selected is or is not stateless. It works like this:
1: if the "stateless" is picked, the "latest" templates show up
2: if you pick any template, the dialog refreshes according to the settings on this template
3: so, if you pick any template which is NOT "stateless", the dialog will refresh in a way that the VM is NOT stateless and the "latest" templates disappear. So, if you have picked the "latest", your selection will be reset. If you picked any other, only the stateless flag is reset and the list of templates will be updated.

This is the correct behavior, it just may look strange. Previously it behaved the same, just this "stateless" box did not determine the content of the template list so it was not that visible.

@Sefi: could you please confirm this is how it behaves?

After a chat with Sefi: there is one actual problem - when the template which actually is the "latest" is not stateless, it can not be selected in new VM dialog.

the majority of the problem is fixed, please open a separate bug for minor issues (will likely need to wait for 4.0)

Verified again on rhevm-3.6.5.1-0.1.el6.noarch according to steps mentioned in comment#16.

As for the remaining issue, opened a separate bug - 
https://bugzilla.redhat.com/show_bug.cgi?id=1323780.

3.6.5 released

Created attachment 1153299 [details]
new VM dialog in version 3.6.5.3-0.1.el6 is still showing duplicates for non-stateless VMs

Reopening.

I just checked new VM dialog in 3.6.5.3-0.1.el6 and it still shows duplicites even though none of templates is stateless and that the stateless checkbox is unchecked.

Screenshot is attached.

It looks like it happens only in userportal and only on initialization. E.g. after selecting and unselecting "stateless" makes the "latest" filter properly.

Pushing to 4.0

oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.

Verified with ovirt-engine-4.0.0.2-0.1.el7ev.noarch according to comments 16-18.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-1743.html