+++ This bug was initially created as a clone of Bug #1219442 +++ Description of problem: Do not run scheduler if ovirt scheduler is running Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: --- Additional comment from Anand Avati on 2015-05-07 08:54:05 EDT --- REVIEW: http://review.gluster.org/10641 (snapshot/scheduler: Do not enable scheduler if another scheduler is running) posted (#1) for review on master by Avra Sengupta (asengupt) --- Additional comment from Anand Avati on 2015-05-12 02:24:45 EDT --- REVIEW: http://review.gluster.org/10641 (snapshot/scheduler: Do not enable scheduler if another scheduler is running) posted (#3) for review on master by Avra Sengupta (asengupt) --- Additional comment from Anand Avati on 2015-05-12 03:34:31 EDT --- REVIEW: http://review.gluster.org/10641 (snapshot/scheduler: Do not enable scheduler if another scheduler is running) posted (#4) for review on master by Avra Sengupta (asengupt)
Fixed with https://code.engineering.redhat.com/gerrit/#/c/49697/
Enabled scheduler through ovirt. Tried enabled scheduler through cli then got error [root@rhs-client33 ~]# snap_scheduler.py enable snap_scheduler: Failed to enable snapshot scheduling. Error: Another scheduler is active. However after disabling scheduler from ovirt , can't enable scheduler from cli. It doesn't remove entry from file cat /var/run/gluster/shared_storage/snaps/current_scheduler Hence moving bug to assigned state
When we create first snapshot schedule from oVirt, the gluster CLI snapshot schedule gets disabled. But when we delete the last schedule from oVirt, that does not mean that we are not going to create schedules from oVirt in future, so during deletion of snapshot schedule in oVirt we dont go back and enable CLI snapshot schedule. This is intentional and I feel its correct behaviour. And once oVirt is there, it is supposed to be used always for any snapshot scheduling. If admin does not want to use oVirt at all (which is not likely), he should manually enable the CLI scheduler from gluster CLI. Please share your thoughts.
I think as agreed upon, once ovirt schedules the first job it takes onus of the entire scheduling till it is present or running on the system. which means even if there isn't a snap schdeuled in the system in the future, while ovirt is running, the CLI scheduler should not be allowed to be enabled, and all snapshots will be scheduled through ovirt
[root@rhs-client33 snaps]# cat current_scheduler ovirt [root@rhs-client33 snaps]# snap_scheduler.py enable snap_scheduler: Failed to enable snapshot scheduling. Error: Another scheduler is active. Bug verified on build glusterfs-3.7.1-7.el6rhs.x86_64.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-1495.html