Bug 1294511 - Pool's template version doesn't update when set to latest and a new version is created
Pool's template version doesn't update when set to latest and a new version i...
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt (Show other bugs)
3.6.2
Unspecified Unspecified
high Severity urgent (vote)
: ovirt-3.6.5
: 3.6.5.1
Assigned To: Arik
sefi litmanovich
: AutomationBlocker, Regression
: 1323493 1323595 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-28 11:21 EST by sefi litmanovich
Modified: 2016-04-21 10:36 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-21 10:36:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑3.6.z+
rule-engine: blocker+
mgoldboi: planning_ack+
tjelinek: devel_ack+
mavital: testing_ack+


Attachments (Terms of Use)
engine log (481.30 KB, application/x-gzip)
2015-12-28 11:21 EST, sefi litmanovich
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 55185 master MERGED core: prevent a race on add template version 2016-03-24 09:36 EDT
oVirt gerrit 55219 ovirt-engine-3.6 MERGED core: prevent a race on add template version 2016-03-25 03:35 EDT
oVirt gerrit 55348 master MERGED core: prevent a race on add template version - done right 2016-03-29 04:07 EDT
oVirt gerrit 55378 ovirt-engine-3.6 MERGED core: prevent a race on add template version - done right 2016-03-29 07:44 EDT
oVirt gerrit 55557 ovirt-engine-3.6.5 MERGED core: prevent a race on add template version - done right 2016-04-03 07:03 EDT

  None (edit)
Description sefi litmanovich 2015-12-28 11:21:22 EST
Created attachment 1110038 [details]
engine log

Version-Release number of selected component (if applicable):

rhevm-3.6.2-0.1.el6.noarch

How reproducible:
always

Steps to Reproduce:

1. Create a template of some OS.
2. Create a pool with some vms (in my case 5) using the template you created - set version to latest.
3. Start 2 vms from the pool and create a new file in one of them.
4. stop the vm with the new file. 
5. make a template from that vm and set it as a new version of the previously used template.

Actual results:

1.The vm which is still up doesn't get the delta sign expected.
2.The other vms which are down are not deleted and re created with the new template.
3. When the started vm is stopped it then IS deleted and re created with the correct version.
4. If one of the vms which were down is started and the stopped again it also is deleted and re createed with the correct version.

Expected results:

Once the new template version is created the delta sign should appear on the started vm and the vms down should be deleted and re created with the right template version.


Additional info:

In the attached log, the vm pool name is 'template_version' and has 5 vms.
the name of the template is 'golden_mixed_virtio_template' and the scenario was creating the 5th sub version from vm 'template_version-1' while the pool is set to 'latest' which was the 4th sub - version. the vm which was up was 'template_version-2' and the other vms down were 'template_version-3/4/5'.

Creation of the template can be found in the log:

2015-12-28 17:41:32,193 INFO  [org.ovirt.engine.core.bll.AddVmTemplateCommand] (ajp-/127.0.0.1:8702-18) [b6c75f1] Lock Acquired to object 'EngineLock:{exclusiveLocks='null', sharedLocks='[2ab87f2c-0b59-4c98-8f27-6c555e898bef=<TEMPLATE, ACTION_TYPE_FAILED_OBJECT_LOCKED>]'}'
Comment 1 Michal Skrivanek 2016-01-29 08:47:49 EST
what kind of pool is it?

when you stop the VM from pool the snapshot is reverted and you've lost that file...so then when you create a new version from the same VM it is exactly the same as the previous version

there's no immediate reaction when you add a version. On next VM startup the new version is used, that's all.
Comment 2 sefi litmanovich 2016-02-07 07:58:54 EST
It's an automatic pool, and the VMs are started by admin and not as user, therefore not started as stateless vms as you suggest (there is no snapshot)

I also don't agree with the last part of you comment, as far as I know, when a new version is created which is different than the previous version then any vm that is up (thus works on top of previous version) should be marked for reboot to apply new version.
And the other VMs are supposed to be deleted and re-created on top of the new version.
That is at least the behaviour when replacing a version to a different version (not as latest pointer).
e.g. If I would do the same flow but instead of keeping the template version pointer on latest I'd change the flow to:

1. Create a template of some OS.
2. Create a pool with some vms (in my case 5) using the template you created - set version to (1).
3. Start 2 vms from the pool and create a new file in one of them.
4. stop the vm with the new file. 
5. make a template from that vm and set it as a new version of the previously used template.
6. edit pool -> set template version to (2).

This flow will result with the expected behaviour. Seeing as this flow and the original should be equivalent I insist this is a bug with usage of the 'latest' pointer.
Comment 5 Red Hat Bugzilla Rules Engine 2016-02-29 06:27:41 EST
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
Comment 6 Red Hat Bugzilla Rules Engine 2016-02-29 06:42:52 EST
This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Comment 7 Arik 2016-03-21 13:10:48 EDT
Lets separate two things:

1. The indication for 'next-run' configuration (that will be applied on next run) - it was designed in parallel to the template version feature. There was no requirement to show this indication for a VM that is set with 'latest' template when new version is created (it was designed only for new configuration that is set for the specific VM). If we want to present it in that case as well - then it should be tracked as RFE and not as a regression.

2. The problem that some of the VMs were not upgraded to the latest version - I can't reproduce that. Looking at the attached log, I see that the VM template_version-3 for example was deleted and recreated.
Sefi, can try to reproduce it on latest 3.6 and see if it is reproduced?
Comment 8 sefi litmanovich 2016-03-22 04:19:19 EDT
2. Re produced once more on rhevm-3.6.4-0.1.el6.noarch.
Re iterating on the steps:

1. Created a vm pool with 5 VMs from some template with rhel 7.2 on it, set to latest template version.
2. Started 2/5 of the VMs as admin (vms start normally - not stateless).
3. Create a file in 1 of the running vms then stop it.
4. Create a new template version from that VM.

Result:
The 3 Vms are not re created.
The running vm has no indicator - I think there should be an indicator, I can open the RFE so discussion can continue there.

5. start 1 of the 3 VMs which were untouched.

Result:
Vm doesn't contain the new file.

6. stop VM-2 (the one that was started and untouched) and VM-3 from last step.

Result:
Now these VMs are re created - file appear when started.
the last 2 untouched VMs (4,5) are still not re created.
Comment 9 Arik 2016-03-22 05:07:05 EDT
(In reply to sefi litmanovich from comment #8)
Alright, that's good that you managed to reproduce it.
So please attach the engine log and specify the IDs of the VMs in the pool and specifically these that have not been upgraded to the latest template version
Comment 11 Arik 2016-03-24 05:13:15 EDT
We didn't manage to reproduce it with a debugger on Sefi's environment.

We identified a possible race and I was able to reproduce it with some breakpoints. Not sure that this the cause to this bug, but chances are relatively high (in my opinion) and with no further information that's probably the best we can do at the moment.

Therefore, proposing a simple fix to prevent this race and hopefully it will eliminate this issue.
Comment 12 Mike McCune 2016-03-28 18:13:31 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 13 Michal Skrivanek 2016-03-31 09:47:51 EDT
not really in 3.6.5 yet
Comment 14 Red Hat Bugzilla Rules Engine 2016-03-31 09:47:55 EDT
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 15 Michal Skrivanek 2016-03-31 09:49:54 EDT
*** Bug 1322865 has been marked as a duplicate of this bug. ***
Comment 16 Michal Skrivanek 2016-04-04 02:31:03 EDT
*** Bug 1323493 has been marked as a duplicate of this bug. ***
Comment 17 sefi litmanovich 2016-04-04 12:39:03 EDT
Verified on same env where the bug appeared after upgrade to: rhevm-3.6.5.1-0.1.el6.noarch according to the steps in description.
Comment 18 Roy Golan 2016-04-05 04:06:50 EDT
*** Bug 1323595 has been marked as a duplicate of this bug. ***

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