-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
reset_confirmation in reset.yml #10288
Conversation
reset confirmation user input fix
Welcome @somewho! |
Hi @somewho. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
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.
Thanks! I am guessing this happened since we updated Ansible :(
/lgtm
/ok-to-test
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.
/approve
Looks good
Actually this does fail in CI:
|
Ah, yes. It is unable to evaluate the conditional. |
added default for non-interactive run in ci/cd
* skip reset_confirmation promtp when reset_confirmation is defined via extra-vars option (for tests) * check both string type and object type with user_input for reset_confirmation var
'Cause of I've made some changes to deal with both string via extra-vars command line option and with object type when registered by ansible.builtin.pause module prompt Also I've found another workaround in playbooks/remove_node.yml
but is "default('yes')" behavior acceptable? |
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.
Oh indeed nice catch! I would prefer though that you change the register to something else for backward compatibility with the variable on the ansible cli (reset_confirmation_prompt
maybe?) and have an or
instead of defining the same variable twice at two places. This would be less confusing/more readable IMO
With reset_confirmation_prompt:
b.
In both cases have to use a default for each of the variables |
Both looks fine I am not sure if a works though maybe this would work better (but b is also fine 🤷♂️) |
improvement inspired by: #10288 (comment)
I think I found a good and fairly clear solution:
|
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.
Looks good and indeed very clean thanks!
/lgtm
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.
@somewho Thank you for the fix 🙇
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: floryut, MrFreezeex, Pradumnasaraf, somewho The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
* Update reset.yml reset confirmation user input fix * Update reset.yml added default for non-interactive run in ci/cd * fix reset_confirmation in reset.yml * skip reset_confirmation promtp when reset_confirmation is defined via extra-vars option (for tests) * check both string type and object type with user_input for reset_confirmation var * reset_confirmation_prompt in conjunction with reset_confirmation improvement inspired by: kubernetes-sigs#10288 (comment)
What type of PR is this?
/kind bug
What this PR does / why we need it:
reset confirmation user input fix
Which issue(s) this PR fixes:
Fixes #10287
Special notes for your reviewer:
Does this PR introduce a user-facing change?: