Omer Frenkel has posted comments on this change.
Change subject: engine: Refresh gluster data periodically
......................................................................
Patch Set 6: (6 inline comments)
....................................................
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 {
no need to a private ctor?
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]");
this will be written every 5 sec (by default)
i think its better in debug
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
maybe add debug log for skipping host as done for cluster
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)) {
why not just run removeVdsCommand?
( and also for other actions, where command exist, not better just to use it?
instead of doing the execute code again )
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());
in general bll classes should not use any VdsBroker class directly,
only through runVdsCommand.
so in order to do the above please run the following (like in removeVdsCommad):
Backend.getInstance().getResourceManager()
.RunVdsCommand(VDSCommandType.RemoveVds, new
RemoveVdsVDSCommandParameters(server.getId()));
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);
AFAIK, 'ALERT' is a special severity for power-management operations only
please use warn and error, or consult with infra guys (eli) about the option of
using alert severity
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
