Hide Forgot
Description of problem: -Looking for the ability to control all needed configs that change in /etc/origin/master/* via ansible. Example would be having ansible control all changes made to the scheduler. Version-Release number of selected component (if applicable): OSE 3.1 Additional info: - Also changes made in /etc/sysconfig would be nice if ansible could control
Would it be helpful in the short term to product admins a way to specify a custom configuration file so that they could control these files themselves? Alternatively, if you provide a prioritized list of fixes we can address them in order.
The scheduler config has been addressed in https://github.com/openshift/openshift-ansible/pull/1680 It doesn't really make sense to support modifying the policy config on disk since it is only loaded if the policy doesn't already exist in etcd.
check on openshift-ansible -b master scenarios 1: Install env without 'openshift_master_scheduler_predicates' and 'openshift_master_scheduler_priorities' check the configuration file, compare with the configuration from template, the "ServiceSpreadingPriority" is changed to 'SelectorSpreadPriority', is it by design? scenarios 2: Install ha-master env with 'openshift_master_scheduler_predicates' and 'openshift_master_scheduler_priorities' <--snip--> openshift_master_scheduler_predicates=[{"name": "MatchNodeSelector"}, {"name": "PodFitsResources"}, {"name": "PodFitsPorts"}, {"name": "NoDiskConflict"}, {"name" : "MaxEBSVolumeCount"}] openshift_master_scheduler_priorities=[{"name": "LeastRequestedPriority", "weight": 1}, {"name": "ServiceSpreadingPriority", "weight": 1}] <--snip--> check the configuration file after installation, the specified value take effect. For the first scenario, if the change is by design, QE will move this issue to VERIFIED.
Yes, the change from ServiceSpreadingPriority to SelectorSpreadPriority was to address the following Github Issue: https://github.com/openshift/openshift-ansible/issues/476
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://access.redhat.com/errata/RHBA-2016:1065