Shireesh Anjal has posted comments on this change.
Change subject: engine: Refresh gluster data periodically
......................................................................
Patch Set 6: (6 inline comments)
Responses to review comments in-line. New patch-set to follow with some of the
comments incorporated.
....................................................
File
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/gluster/GlusterManager.java
Line 58: * This class is responsible for keeping the Gluster related data of
engine in sync with the actual data retrieved from
Line 59: * GlusterFS. This helps to make sure that any changes done on Gluster
servers using the Gluster CLI are propagated to
Line 60: * engine as well.
Line 61: */
Line 62: public class GlusterManager {
Done
Line 63: private static final String ENTITY_BRICK = "brick";
Line 64: private static final String ENTITY_OPTION = "option";
Line 65: private static GlusterManager instance = new GlusterManager();
Line 66: private static Log log = LogFactory.getLog(GlusterManager.class);
Line 115: * which uses 'volume status' to fetch and update status of
volume bricks.
Line 116: */
Line 117: @OnTimerMethodAnnotation("refreshLightWeightData")
Line 118: public void refreshLightWeightData() {
Line 119: log.info("Refreshing Gluster Data [lightweight]");
Done
Line 120: List<VDSGroup> clusters = getClusterDao().getAll();
Line 121:
Line 122: for (VDSGroup cluster : clusters) {
Line 123: if (cluster.supportsGlusterService()) {
Line 152: private void refreshServerData(VDSGroup cluster, VDS upServer,
List<VDS> existingServers) {
Line 153: if (cluster.supportsVirtService()) {
Line 154: // If the cluster supports virt service as well, we
should not be removing any servers from it, even if they
Line 155: // have been removed from the Gluster cluster using the
Gluster cli, as they could potentially be used for
Line 156: // running VMs
Done
Line 157: return;
Line 158: }
Line 159:
Line 160: Set<GlusterServerInfo> fetchedServers = fetchServers(cluster,
upServer, existingServers);
Line 164: }
Line 165:
Line 166: private void removeDetachedServers(List<VDS> existingServers,
Set<GlusterServerInfo> fetchedServers) {
Line 167: for (VDS server : existingServers) {
Line 168: if (isRemovableStatus(server.getstatus()) &&
serverDetached(server, fetchedServers)) {
1) Since this is not a 'regular' remove vds flow, the canDoAction may fail e.g.
Noramally canDoAction fails if if there are volume bricks on the given server.
This would happen when user has removed bricks as well as the server from the
cluster using gluster CLI, and we haven't synced the volumes/bricks yet.
2) The 'regular' remove vds flow (when gluster is enabled), in it's
executeCommand() method, would try to perform a 'peer detach' of the server,
which will fail has the user has already done it from the gluster CLI.
Line 169: RemoveVdsStatisticsFromDb(server);
Line 170: RemoveVdsDynamicFromDb(server);
Line 171: RemoveVdsStaticFromDb(server);
Line 172:
Line 170: RemoveVdsDynamicFromDb(server);
Line 171: RemoveVdsStaticFromDb(server);
Line 172:
Line 173: // remove the server from resource manager
Line 174:
ResourceManager.getInstance().RemoveVds(server.getId());
I can't do this because of the two reasons mentioned above. Would be happy to
change this if there is some other better way. How about putting this logic in
a common place and invoke it from both GlusterManager and RemoveVdsCommand?
Line 175:
Line 176: log.debugFormat("Server {0} has been removed directly
using the gluster CLI. Removing it from engine as well.",
Line 177: server.getvds_name());
Line 178: logServerMessage(server,
AuditLogType.GLUSTER_SERVER_REMOVED_FROM_CLI);
....................................................
File
backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/auditloghandling/AuditLogDirector.java
Line 80: mSeverities.put(AuditLogType.GLUSTER_HOST_REMOVE_FAILED,
AuditLogSeverity.ERROR);
Line 81:
mSeverities.put(AuditLogType.GLUSTER_VOLUME_REPLACE_BRICK_FAILED,
AuditLogSeverity.ERROR);
Line 82:
mSeverities.put(AuditLogType.GLUSTER_VOLUME_REPLACE_BRICK_START,
AuditLogSeverity.NORMAL);
Line 83:
mSeverities.put(AuditLogType.GLUSTER_VOLUME_REPLACE_BRICK_START_FAILED,
AuditLogSeverity.ERROR);
Line 84: mSeverities.put(AuditLogType.GLUSTER_VOLUME_CREATED_FROM_CLI,
AuditLogSeverity.ALERT);
Done
Line 85: mSeverities.put(AuditLogType.GLUSTER_VOLUME_DELETED_FROM_CLI,
AuditLogSeverity.ALERT);
Line 86:
mSeverities.put(AuditLogType.GLUSTER_VOLUME_OPTION_SET_FROM_CLI,
AuditLogSeverity.ALERT);
Line 87:
mSeverities.put(AuditLogType.GLUSTER_VOLUME_OPTION_RESET_FROM_CLI,
AuditLogSeverity.ALERT);
Line 88:
mSeverities.put(AuditLogType.GLUSTER_VOLUME_PROPERTIES_CHANGED_FROM_CLI,
AuditLogSeverity.ALERT);
--
To view, visit http://gerrit.ovirt.org/7288
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I6b61eb6e93105e46e2706eac1d94bc10717224c2
Gerrit-PatchSet: 6
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Shireesh Anjal <[email protected]>
Gerrit-Reviewer: Omer Frenkel <[email protected]>
Gerrit-Reviewer: Shireesh Anjal <[email protected]>
Gerrit-Reviewer: Yair Zaslavsky <[email protected]>
Gerrit-Reviewer: oVirt Jenkins CI Server
_______________________________________________
Engine-patches mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-patches
