Omer Frenkel has posted comments on this change. Change subject: core: vmsMonitoring - save info to be sooner ......................................................................
Patch Set 1: (4 comments) https://gerrit.ovirt.org/#/c/39406/1//COMMIT_MSG Commit Message: Line 3: AuthorDate: 2015-03-31 17:48:49 +0300 Line 4: Commit: Omer Frenkel <ofren...@redhat.com> Line 5: CommitDate: 2015-03-31 17:48:49 +0300 Line 6: Line 7: core: vmsMonitoring - save info to be sooner > or: Done Line 8: Line 9: the new structure of the host-vms monitoring caused the save vms info to Line 10: db to be called later in the cycle than it used to be. Line 11: Line 9: the new structure of the host-vms monitoring caused the save vms info to Line 10: db to be called later in the cycle than it used to be. Line 11: Line 12: this caused issues in operations that executed in afterVMsRefreshTreatment, that Line 13: assumed new information in the db. > how about Done Line 14: Line 15: in this patch the save-to-db moved back into the refreshVmStats from the Line 16: afterVMsRefreshTreatment, also with processExternallyManagedVms and Line 17: processVmsWithDevicesChange that originally happened before the save to https://gerrit.ovirt.org/#/c/39406/1/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/VmsMonitoring.java File backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/VmsMonitoring.java: Line 167: * this filtering. Line 168: */ Line 169: private void refreshVmStats() { Line 170: for (Pair<VM, VmInternalData> pair : monitoredVms) { Line 171: // TODO filter out migratingTo VMs if no action is taken on them > I mean, if we go through here with MigratingTo Vms and the later processing the code inside already ignores migratingTo vms, this is why we think of filtering it out to begin with - hence this TODO. handOverVm() happens on the source host, so vm is in transition from migratingFrom to down, migratingTo is only on the dest host Line 172: if (tryLockVmForUpdate(pair)) { Line 173: VmAnalyzer vmAnalyzer = new VmAnalyzer( Line 174: pair.getFirst(), Line 175: pair.getSecond(), Line 244: // run all vms that crashed that marked with auto startup Line 245: getVdsEventListener().runFailedAutoStartVMs(autoVmsToRun); Line 246: Line 247: // process all vms that went down Line 248: getVdsEventListener().processOnVmStop(movedToDownVms); > was it intentional to change the order of the calls to processOnVmStop and yes, i compared the order with previous code, and found it got changed, so changed back Line 249: } Line 250: Line 251: private void processVmsWithDevicesChange() { Line 252: // Handle VM devices were changed (for 3.1 cluster and above) -- To view, visit https://gerrit.ovirt.org/39406 To unsubscribe, visit https://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I5e69b0ba20588db55bb40e9ba6ca5472c3efe687 Gerrit-PatchSet: 1 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Omer Frenkel <ofren...@redhat.com> Gerrit-Reviewer: Arik Hadas <aha...@redhat.com> Gerrit-Reviewer: Michal Skrivanek <michal.skriva...@redhat.com> Gerrit-Reviewer: Omer Frenkel <ofren...@redhat.com> Gerrit-Reviewer: Roy Golan <rgo...@redhat.com> Gerrit-Reviewer: Shmuel Leib Melamud <smela...@redhat.com> Gerrit-Reviewer: automat...@ovirt.org Gerrit-Reviewer: oVirt Jenkins CI Server Gerrit-HasComments: Yes _______________________________________________ Engine-patches mailing list Engine-patches@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-patches
