Livnat Peer has posted comments on this change.
Change subject: DO NOT SUBMIT - wip - core: adding service policy for gluster
integration
......................................................................
Patch Set 4: (6 inline comments)
I think that generally it captures the spirit of separating gluster and virt
services. My main concern is that the API should not include a service specific
API.
About the servicePolicy name I agree with Juan that we should find a more
reflective name.
How about - MonitoringStrategy - for the API, VirtStrategy and GlusterStrategy
- for the implementations.
....................................................
File
backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/ServicePolicyFactory.java
Line 16:
Do we want it to return a single service or a list that currently contains only
one service.
Do we want to have also a generic service to have all the code which is shared
between virt and gluster or simply leave it part of the flow.
....................................................
File
backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/ServicePolicy.java
Line 8: public interface ServicePolicy {
I think the API should be more general with no specific reference to CPU or KVM
which are virt centric.
....................................................
File
backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/VdsManager.java
Line 235: }
What we are doing here is basically looking for reasons not to monitor the host.
I would add a method that validates something like enableHostMonitoring(), and
in the general service we'll have the checks bellow, in the virt service we'll
have the non-operational + running VMs and in gluster service it will be as
simple as return true.
Line 423: UpdateDynamicData(vds.getDynamicData());
CPU flags are relevant only for virt, should we keep them in the general flow?
Line 567: }
In the shared service I don't think we need reference to KVM.
Maybe move all KVM related validations into the virt service in a general API
name, like areServiceRequirmentsMet() or something similar.
....................................................
File
backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/VdsUpdateRunTimeInfo.java
Line 196: _firstStatus = _vds.getstatus();
we calculate it in the VdsManager, did you think about passing the service as
parameter instead of retaking it from the factory?
--
To view, visit http://gerrit.ovirt.org/2387
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I5edc263dae23236015260d83a933e8a3a93e4523
Gerrit-PatchSet: 4
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Oved Ourfali <[email protected]>
Gerrit-Reviewer: Juan Hernandez <[email protected]>
Gerrit-Reviewer: Livnat Peer <[email protected]>
Gerrit-Reviewer: Moti Asayag <[email protected]>
Gerrit-Reviewer: Omer Frenkel <[email protected]>
Gerrit-Reviewer: Oved Ourfali <[email protected]>
Gerrit-Reviewer: Shireesh Anjal <[email protected]>
Gerrit-Reviewer: Shireesh Anjal <[email protected]>
_______________________________________________
Engine-patches mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-patches
