This repository has been archived by the owner on Oct 30, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Allow value to be bool where 'yes'/'no' are in choices #2593
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tmshn
changed the title
Allow yesno bool
Allow value to be bool where 'yes'/'no' are in choices
Jul 20, 2016
Thanks @tmshn. To the current maintainers, @sayap, @Java1Guy, @alcamie101, @drybjed, @bcoca please review according to guidelines (http://docs.ansible.com/ansible/developing_modules.html#module-checklist) and comment with text 'shipit', 'needs_revision' or 'close_me' as appropriate. [This message brought to you by your friendly Ansibull-bot.] |
abadger
added a commit
to abadger/ansible
that referenced
this pull request
Aug 4, 2016
uri: follow_redirects: no Will lead yaml to set follow_redirects=False. This is problematic when the module parameter is not a boolean value but a string. For instance: follow_redirects = dict(required=False, default='safe', choices=['all', 'safe', 'none', 'yes', 'no']), Our parameter validation code ends up getting follow_redirects="False" instead of "no". The 100% fix is for the user to quote their strings in playbooks like: uri: follow_redirects: "no" But we can fix quite a few common cases by trying to switch "False" back into the string that it was specified as. We only do this if there is only one correct choices value that could have been specified. In the follow_redirects example, a value of "True" only maps back to "yes" and a value of "False" only maps back to "no" so we can do this. If choices also contained "on" and "off" then we couldn't map back safely and would need to force the module author to change the module to handle this case. Fixes parts of the following PRs: * ansible/ansible-modules-core#4220 * ansible/ansible-modules-extras#2593
Same as ansible/ansible-modules-core#4220, this PR is pended until ansible/ansible#16961 will be merged. needs_revision |
abadger
added a commit
to ansible/ansible
that referenced
this pull request
Aug 5, 2016
uri: follow_redirects: no Will lead yaml to set follow_redirects=False. This is problematic when the module parameter is not a boolean value but a string. For instance: follow_redirects = dict(required=False, default='safe', choices=['all', 'safe', 'none', 'yes', 'no']), Our parameter validation code ends up getting follow_redirects="False" instead of "no". The 100% fix is for the user to quote their strings in playbooks like: uri: follow_redirects: "no" But we can fix quite a few common cases by trying to switch "False" back into the string that it was specified as. We only do this if there is only one correct choices value that could have been specified. In the follow_redirects example, a value of "True" only maps back to "yes" and a value of "False" only maps back to "no" so we can do this. If choices also contained "on" and "off" then we couldn't map back safely and would need to force the module author to change the module to handle this case. Fixes parts of the following PRs: * ansible/ansible-modules-core#4220 * ansible/ansible-modules-extras#2593
abadger
added a commit
to ansible/ansible
that referenced
this pull request
Aug 5, 2016
uri: follow_redirects: no Will lead yaml to set follow_redirects=False. This is problematic when the module parameter is not a boolean value but a string. For instance: follow_redirects = dict(required=False, default='safe', choices=['all', 'safe', 'none', 'yes', 'no']), Our parameter validation code ends up getting follow_redirects="False" instead of "no". The 100% fix is for the user to quote their strings in playbooks like: uri: follow_redirects: "no" But we can fix quite a few common cases by trying to switch "False" back into the string that it was specified as. We only do this if there is only one correct choices value that could have been specified. In the follow_redirects example, a value of "True" only maps back to "yes" and a value of "False" only maps back to "no" so we can do this. If choices also contained "on" and "off" then we couldn't map back safely and would need to force the module author to change the module to handle this case. Fixes parts of the following PRs: * ansible/ansible-modules-core#4220 * ansible/ansible-modules-extras#2593 (cherry picked from commit 6db6edf)
tmshn
force-pushed
the
allow_yesno_bool
branch
from
August 14, 2016 07:24
8c17a23
to
ac23228
Compare
…dule. ('create_connection_bridge(self)' and 'modify_connection_bridge(self)' are not implemented yet?)
tmshn
force-pushed
the
allow_yesno_bool
branch
from
August 14, 2016 07:38
ac23228
to
1ee56fb
Compare
Thanks to @abadger (ansible/ansible#16961), modification for case 2 is meaningless any more. Thus, I dropped commit on Other than that, below modules are welcome for reviews. Case 1 Case 3
|
abadger
pushed a commit
that referenced
this pull request
Aug 17, 2016
* Changed type of 'details' argument to bool on ecs_service_facts module. * Changed type of 'autostart' argument to bool on virt_* modules. * Changed types of 'autoconnect' and 'stp' argument to bool on nmcli module. ('create_connection_bridge(self)' and 'modify_connection_bridge(self)' are not implemented yet?) * Added conversion of 'value' argument when 'vtype' is boolean on debconf module.
Thanks @tmshn ! Merged to devel and cherry-picked to stable-2.1. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NOTE This pull request work on same issue as #4220 on ansible-modules-core. Therefore, below comment is almost copy-and-paste.
ISSUE TYPE
COMPONENT NAMES
ecs_service_facts
virt_net
virt_pool
portage
nmcli
debconf
ANSIBLE VERSION
SUMMARY
Many arguments from many modules has limited choices including
'yes'
and/or'no'
as a option. However, in some case, these are treated as string type; boolean values cause error.This pull request fix this problem, in the following two way:
1. Change type to bool
If choices are only
'yes'
and'no'
, this argument can be easily modified to bool type. Even parameter is passed as string, it will be converted to boolean, so it is 100% backward compatible.Modules:
ecs_service_facts
virt_net
virt_pool
nmcli
Example:
ecs_service_facts
module's case2. Add options to catch boolean
UPDATED Thanks to ansible/ansible#16961, this case doesn't need to be considered any more.
If choices contains other values than'yes'
or'no'
, this argument should be kept to be treated as string. In this case, if you pass boolean argument here, it will be converted to'True'
or'False'
respectively. Therefore, adding them to the choices will solve the problem.Modules:portage
Example:portage
module's caseThe choices ofsync
argument ofportage
modules contain"web"
, so it cannot be treated as boolean.Another example:
debconf
module's caseThe
value
argument ofdebconf
modules does not have any explicit choices in the modules source code, but actually its choices are limited whenvtype
is'boolean'
. So I added conversion process here.