Bug 1438408

Summary: [RFE] Cluster maintenance scheduling policy
Product: [oVirt] ovirt-engine Reporter: Moran Goldboim <mgoldboi>
Component: RFEsAssignee: Martin Sivák <msivak>
Status: CLOSED CURRENTRELEASE QA Contact: Artyom <alukiano>
Severity: high Docs Contact:
Priority: high    
Version: 4.1.0CC: apinnick, bugs, michal.skrivanek, msivak, mtessun, stirabos
Target Milestone: ovirt-4.1.4Keywords: FutureFeature, Triaged
Target Release: 4.1.4.1Flags: rule-engine: ovirt-4.1+
mgoldboi: exception+
mgoldboi: planning_ack+
rule-engine: devel_ack+
mavital: testing_ack+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
The ClusterInMaintenance scheduling policy was added to limit activity in a cluster during maintenance tasks. When set, no new VMs may be started, except highly available VMs. Highly available VMs are still restarted properly upon host failure and any VM can be migrated. Users can create new highly available VMs and start them manually.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2017-07-28 14:20:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: SLA RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1469478    
Bug Blocks: 1488294    
Attachments:
Description Flags
ClusterInUpgrade filter none

Description Moran Goldboim 2017-04-03 11:27:31 UTC 
Description of problem:
upgrading a cluster is a task which requires proper planning wrt to workload distribution and management. spawning new VMs by different users is a scenario that adds complexity to this mechanism, and we would like a way to prevent those operations while allowing normal operation of the cluster while having this policy.

we would like to have a new cluster scheduling policy with the following criteria:
-block new VMs from running
-allow HA VMs failover
-allow live migration
-ability to change to this policy on a live manner
-API/SDK/Ansible support for this change of policy

the output (fail VM run) should indicate that cluster maintenance policy is in place, and thus preventing running new VMs.
Comment 2 Michal Skrivanek 2017-05-04 07:39:03 UTC 
please finally remove the InClusterUpgrade one. It was supposed to be part of the effort by rmohr when it was introducing in 3.6.z, but it still exists. It's useless and misleading ever since 4.0
Comment 5 Martin Sivák 2017-06-14 10:45:21 UTC 
Ok, so we discussed this with Moran and we are fine with the following limitation of scope, but it has to be explicitly documented:

- manually starting a new HA VM is not going to be covered by the policy (will be allowed)
- any user can create HA VM
Comment 6 Yaniv Kaul 2017-06-15 09:39:18 UTC 
Moving to 4.1.4, as it seem to have missed 4.1.3.
Comment 7 Moran Goldboim 2017-06-19 12:26:01 UTC 
*** Bug 1145764 has been marked as a duplicate of this bug. ***
Comment 8 Michal Skrivanek 2017-07-11 07:48:02 UTC 
- still missing a patch to hide/remove the InClusterUpgrade policy which has a confusing name to what this RFE is trying to address (upgrading clusters)
- need to update documentation to remove the InClusterUpgrade from admin guide as well to prevent the implied need to use it for "older" to "newer" OS updates
Comment 9 Artyom 2017-07-18 14:38:42 UTC 
Verified on rhevm-4.1.4.1-0.1.el7.noarch

Change cluster scheduling policy to cluster maintenance

Scenario 1:
===========
1) Start not HA VM - FAILED


Scenario 2:
===========
1) Migrate not HA VM(VM was started before policy) - SUCCSEEDED


Scenario 3:
===========
1) Update non HA VM to be HA and start it - SUCCSEEDED


Scenario 4:
===========
1) Kill HA VM, the engine must restart it - SUCCEEDED


Scenario 5:
===========
1) Put host with HA and not HA VM to maintenance - SUCCEEDED
Comment 10 Avital Pinnick 2017-11-13 13:45:36 UTC 
Created attachment 1351574 [details]
ClusterInUpgrade filter

ClusterInUpgrade filter still appears in New Schedule Policy window. Cluster_Maintenance filter has not been added.
Comment 12 Martin Sivák 2017-11-15 08:19:35 UTC 
This is expected. We removed the predefined in_cluster_upgrade policy and added a predefined cluster_maintenance one.

But we kept the policy units intact. Both ClusterInMaintenance and InClusterUpgrade pair (filter + weight) should still be visible in the drag'n'drop boxes.