Description of problem: The logging deployed failed. openshift_logging_curator_run_timezone is removed from openshift_logging_curator/default/main.yaml. But it still be called in openshift_logging_curator_run_timezone roles/openshift_logging_curator/templates/2.x/curator.j2 Version-Release number of selected component (if applicable): openshift3/ose-ansible:v3.10.119 How reproducible: Always Steps to Reproduce: 1. Deploy logging using openshift-ansible:ose-ansible:v3.10.119 2. 3. Actual results: [openshift_logging_curator : Generate Curator deploymentconfig] *********** Friday 01 March 2019 10:20:18 +0000 (0:00:00.071) 0:01:56.356 ********** ^[[0;31mfatal: [ec2-3-81-14-138.compute-1.amazonaws.com]: FAILED! => {"changed": false, "failed": true, "msg": "AnsibleUndefinedVariable: 'openshift_logging_curator_run_timezone' is undefined"}^[[0m Expected results: succeed Additional info:
Indeed, openshift-ansible/roles/openshift_logging_curator/defaults/main.yml release-3.10 cherry-picked(?) this patch from release-3.11. [1] commit a61443d214d87a3d9d3787c18a9fb858bc036fc2 (origin/pr/11244) Author: Daein Park <bysnupy> Date: Sat Feb 23 23:37:50 2019 +0900 Remove deprecated "openshift_logging_curator_run_timezone variable" as of v3.11 As of v3.11, the "curator" is triggered by "CronJob", so the times are based the timezone of the master where the job is initiated. - Fix: https://bugzilla.redhat.com/show_bug.cgi?id=1680271 The issue is release-3.10 still needs to run with ES2.x and the curator is not triggered by CronJob? If that's the case, can we revert the patch [1]? Joseph, what do you think? What makes me wonder is looking at the test results [2] of this PR [3], I could not tell whether the patch passed the CI test or not... [2] https://openshift-gce-devel.appspot.com/pr/openshift_openshift-ansible/11244 [3] https://github.com/openshift/openshift-ansible/pull/11244
(In reply to Noriko Hosoi from comment #1) > Indeed, openshift-ansible/roles/openshift_logging_curator/defaults/main.yml > release-3.10 cherry-picked(?) this patch from release-3.11. > [1] commit a61443d214d87a3d9d3787c18a9fb858bc036fc2 (origin/pr/11244) > Author: Daein Park <bysnupy> > Date: Sat Feb 23 23:37:50 2019 +0900 > Remove deprecated "openshift_logging_curator_run_timezone variable" as > of v3.11 > As of v3.11, the "curator" is triggered by "CronJob", so the times are > based the timezone of the master where the job is initiated. > - Fix: https://bugzilla.redhat.com/show_bug.cgi?id=1680271 > > The issue is release-3.10 still needs to run with ES2.x It has nothing to do with ES 2 or ES 5. > and the curator is > not triggered by CronJob? This is the problem - in release-3.10 and earlier, curator still uses a deploymentConfig, not a CronJob: https://github.com/openshift/openshift-ansible/blob/release-3.10/roles/openshift_logging_curator/tasks/main.yaml#L69 and openshift_logging_es5_techpreview defaults to false in 3.10: https://github.com/openshift/openshift-ansible/blob/release-3.10/roles/openshift_logging/defaults/main.yml#L16 > If that's the case, can we revert the patch [1]? Yes. > Joseph, what do you think? > > What makes me wonder is looking at the test results [2] of this PR [3], I > could not tell whether the patch passed the CI test or not... It did not pass logging CI because logging CI was skipped! ci/openshift-jenkins/logging Skipped > > [2] > https://openshift-gce-devel.appspot.com/pr/openshift_openshift-ansible/11244 > [3] https://github.com/openshift/openshift-ansible/pull/11244
Note: v3.11 was the first use of CronJob. v3.10 and older use DeploymentConfig.
@Noriko, yes, this variable should be available to users in 3.10. Unfortunately I noticed that the fix for 3.11 was also cherrypicked to 3.10 after it had merged. I created a PR to revert that https://github.com/openshift/openshift-ansible/pull/11265
Fix in openshift-ansible:3.10.121
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-2019:0405