-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
openshift_checks: refactor check results #4913
openshift_checks: refactor check results #4913
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it, thanks @sosiouxme! I focused on some parts, glanced at others, ignored others. Please comment if there's some part you'd want better review.
@@ -69,13 +69,15 @@ def run(self, tmp=None, task_vars=None): | |||
msg=str(e), | |||
) | |||
|
|||
if check.changed: | |||
r["changed"] = True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is okay. Have you considered setting r['changed'] = check.changed
unconditionally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but I thought it wouldn't hurt to allow the check to continue to return it in the result hash if desired for some reason. But thinking about it, why complicate what is really quite simple... "one way to do it" is probably best here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I remembered why I did it this way. I don't want to clutter up every check result in -vvv
output with "changed" when it won't matter for most. I think I'll leave it as-is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. We can omit from checks, but always set it in the task/action plugin level at most once.
Now whether to always include it on the task/action plugin level will depend on how Ansible interpret it when it is missing (default True or default False) ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty sure Ansible defaults to missing == False
For this code, it seemed simplest to always set it at the task level.
def __init__(self, name, msg=None): | ||
# msg is for the message the user will see when this is raised. | ||
# name is for test code to identify the error without looking at msg text. | ||
if msg is None: # for parameter backward compatibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if we swap the order of the arguments we can avoid this little hack?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course, but I like to have the concise identifier first and then the blah blah blah when I'm looking at the code raising an exception. Selfish of me? And for once I thought it would be nice not to force a total transformation to the new method signature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see 👍
@@ -34,6 +42,8 @@ def __init__(self, execute_module=None, task_vars=None, tmp=None): | |||
self._execute_module = execute_module | |||
self.task_vars = task_vars or {} | |||
self.tmp = tmp | |||
# set True when the check makes a change to the host so it can be reported to the user: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/set True/set to True/ ?
s/so it can be reported to the user// ? "reporting to the user" is kind of optional, we don't need to make promises in this comment, but I'll leave it up to you, I'm fine either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
set to True 👍
"report to user" right that can be worded better. All we're doing is marking the task as having made a change so that the sum total of "changed" tasks can be reported at the end of the run. As if anyone cares (but there's always someone). That's all that's "reported" to the user unless they're looking at -vvv
output.
# set to True when the check changes the host so the total "changed" count is accurate

return {"failed": True, "changed": False, "msg": msg} | ||
|
||
curator_pods = self.get_pods_for_component("curator") | ||
self.check_curator(curator_pods) | ||
# TODO(lmeyer): run it all again for the ops cluster |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still relevant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sadly yes... these checks do nothing to examine the ops cluster. The main cluster is far more likely to fall over and affect users though so the focus is right. These little reminders are where they are because ideally we would literally just run the same high-level methods against a different set of pods/services/etc to do ops cluster checks.
pass | ||
|
||
|
||
class LoggingErrorList(OpenShiftCheckException): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps this doesn't need to have "Logging" in the name? It could as well sit next to "OpenShiftCheckException" and be an alternative to it? class OpenShiftCheckExceptionList(OpenShiftCheckException)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't sure if it would be useful anywhere else. I'm not sure any other checks have a need to compile a list of failures instead of just quitting on the first. But again, thinking about it... it will probably come up. I guess I'll generalize it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That name is too long though 🤔
@rhcarvalho you saw the bits I thought you'd find interesting. Thanks for the feedback. I might run the "changed" commit in a different PR; the rest of this is more tedious than I expected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, let's run the tests
aos-ci-test |
@sosiouxme if this is good to go please remove the [WIP] from the title ;) |
It can be good to go. There are a lot of other checks to get the same treatment but there's no need to hold up these changes for that. |
Introduced the 'changed' property for checks that can make changes to track whether they did or not. Rather than the check's own logic having to track this and include it in the result hash, just set the property and have the action plugin insert it in the result hash after running (even if there is an exception). Cleared out a lot of crufty "changed: false" hash entries.
Turn failure messages into exceptions that tests can look for without depending on text meant for humans. Turn logging_namespace property into a method. Get rid of _exec_oc and just use logging.exec_oc.
aos-ci-test |
[merge] |
https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_openshift_ansible/800/ looks like flakes openshift/origin#14829 and openshift/origin#14898 |
https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_openshift_ansible/803/ indicates flakes openshift/origin#8571 and openshift/origin#10162 [merge] again |
Evaluated for openshift ansible merge up to 06a6fb9 |
continuous-integration/openshift-jenkins/merge FAILURE (https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_openshift_ansible/811/) (Base Commit: 0569c50) (PR Branch Commit: 06a6fb9) |
Flake openshift/origin#13977 |
@sosiouxme okay for us to manually merge this after the recent changes that merged in? |
@rhcarvalho yes that would be nice... enough test failures already. |
Going to merge manually as per https://github.com/openshift/openshift-ansible/blob/master/docs/pull_requests.md#manual-merges |
Introduced the 'changed' property for checks that can make changes to track whether they did or not. Rather than the check's own logic having to track this and include it in the result hash, just set the property and have the action plugin insert it in the result hash after running (even if there is an exception).
Cleared out a lot of crufty "changed: false" hash entries.
Refactored logging checks: