+++ This bug is an upstream to downstream clone. The original bug is: +++ +++ bug 1226974 +++ ====================================================================== Description of problem: Please implement 'Sync MoM policy' support in REST API. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: (Originally by Shira Maximov)
Juan, currently there are no hosts under a specific cluster. Where would it be best to add this action? (Originally by Doron Fediuck)
I'll need to understand whth "sync mom policy" means in order to answer. Can you elaborate? (Originally by juan.hernandez)
(In reply to Juan Hernández from comment #2) > I'll need to understand whth "sync mom policy" means in order to answer. Can > you elaborate? Sure. This button triggers sending a command to the relevant VDS with latest information on KSM and ballooning: org.ovirt.engine.core.bll.UpdateMomPolicyCommand The idea is that we usually update mom policy when a host becomes operational (up). However in case of emergency you can issue a command to enable/disable the relevant feature in the selected host. (Originally by Doron Fediuck)
If I understand correctly then this should be an operation of the "host" resource: POST /hosts/{host:id}/syncmompolicy (Originally by juan.hernandez)
(In reply to Juan Hernández from comment #4) > If I understand correctly then this should be an operation of the "host" > resource: > > POST /hosts/{host:id}/syncmompolicy This is what I had in mind. The only issue is that in the UI this option is only available in the cluster main tab (hosts sub tab), and you will not see it in the hosts tab. If you use your suggestion will it make an anomaly compared to the UI? (Originally by Doron Fediuck)
The RESTAPI doesn't need to mirror the UI. The UI is volatile, and the graphical designers may decide to move the button to somewhere else in the future. On the other hand the RESTAPI needs to be stable and backwards compatible. We can't make design decisions based on what the UI does. If the operation affects a host then its place is the /hosts/{host:id} resource. Alternatively, if the operation affects all the hosts in a cluster, then it can be added to the /clusters/{cluster:id} resource, but my understanding is that it is an operation that affects a individual host. (Originally by juan.hernandez)
(In reply to Juan Hernández from comment #6) > > If the operation affects a host then its place is the /hosts/{host:id} > resource. > > Alternatively, if the operation affects all the hosts in a cluster, then it > can be added to the /clusters/{cluster:id} resource, but my understanding is > that it is an operation that affects a individual host. This is acceptable. Thanks. (Originally by Doron Fediuck)
BZ<2>Jira re-sync