Ayal Baron has posted comments on this change.

Change subject: core: handle error when iso domain in maintenance
......................................................................


Patch Set 3: (3 inline comments)

....................................................
File 
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/IsoDomainListSyncronizer.java
Line 87:     }
Line 88: 
Line 89:     /**
Line 90:      * Returns the singleton instance.
Line 91:      * 
You probably need to change a setting in intelliJ or something
Line 92:      * @return Singleton instance of IsoDomainManager
Line 93:      */
Line 94:     public static IsoDomainListSyncronizer getInstance() {
Line 95:         return isoDomainListSyncronizer;


Line 304:                         
refreshIsoDomainFileForStoragePool(storageDomainId,
Line 305:                                 storagePoolId,
Line 306:                                 fileTypeExt);
Line 307:                 if (!refreshSucceeded) {
Line 308:                     log.debugFormat("Failed refreshing Storage domain 
id {0}, for {1} file type in storage pool id {2}.",
why is this debug level and not warn or info?
(I know you did not change this)
Line 309:                             storageDomainId,
Line 310:                             fileTypeExt,
Line 311:                             storagePoolId);
Line 312:                     // set a mock repository file meta data with 
storage domain id and storage pool id.


Line 309:                             storageDomainId,
Line 310:                             fileTypeExt,
Line 311:                             storagePoolId);
Line 312:                     // set a mock repository file meta data with 
storage domain id and storage pool id.
Line 313:                     RepoFileMetaData repoFileMetaData = new 
RepoFileMetaData();
Actually I'm not sure this doesn't introduce a regression.
fetchIsoDomains calls resetProblematicList
and then it calls updateCachedIsoFileListFromVdsm which in turn calls 
refreshIsoDomain (current method) so problematicRepoFileList will not include 
the previously problematic domains which are inactive.
Skipping this would assume it does.  So regression would depend on where we use 
problematicRepoFileList and what assumptions we have about it (I didn't have 
the patience to track that as well)
Line 314:                     repoFileMetaData.setStoragePoolId(storagePoolId);
Line 315:                     repoFileMetaData.setRepoDomainId(storageDomainId);
Line 316:                     repoFileMetaData.setFileType(fileTypeExt);
Line 317: 


--
To view, visit http://gerrit.ovirt.org/11449
To unsubscribe, visit http://gerrit.ovirt.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ide53f42c087ffbc9240cccc033e809ff8117ec8c
Gerrit-PatchSet: 3
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Alissa Bonas <abo...@redhat.com>
Gerrit-Reviewer: Alissa Bonas <abo...@redhat.com>
Gerrit-Reviewer: Allon Mureinik <amure...@redhat.com>
Gerrit-Reviewer: Ayal Baron <aba...@redhat.com>
Gerrit-Reviewer: Eli Mesika <emes...@redhat.com>
Gerrit-Reviewer: Liron Aravot <lara...@redhat.com>
Gerrit-Reviewer: Maor Lipchuk <mlipc...@redhat.com>
_______________________________________________
Engine-patches mailing list
Engine-patches@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-patches

Reply via email to