Skip to content
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

Support ok_when condition for tasks. #12710

Closed
ypid opened this issue Oct 12, 2015 · 8 comments
Closed

Support ok_when condition for tasks. #12710

ypid opened this issue Oct 12, 2015 · 8 comments
Labels
affects_1.9 This issue/PR affects Ansible v1.9 feature This issue/PR relates to a feature request. needs_info This issue requires further information. Please answer any outstanding questions. support:core This issue/PR relates to code supported by the Ansible Engineering Team.

Comments

@ypid
Copy link
Contributor

ypid commented Oct 12, 2015

ISSUE TYPE

Feature Idea

COMPONENT NAME

core

ANSIBLE VERSION
ansible 1.9.3
CONFIGURATION

Default configuration

OS / ENVIRONMENT

Debian

SUMMARY

Add a ok_when condition to tasks. When it evaluates to True, dont run the task and show OK. When it evaluates to False or it is missing and when evaluates to True, run the task.
I know I could run the Install WordPress plugins task for each plugin but that is time consuming when you have a big list of plugins as the wp command seems to have a high startup time.

STEPS TO REPRODUCE

Example play which would benefit form this feature.

- name: Get list of installed WordPress plugins
  command: 'wp plugin list --format=json'
  sudo_user: '{{ wordpress_user }}'
  args:
    chdir: '{{ wordpress_root }}'
  changed_when: False
  always_run: True
  register: wordpress_plugin_list_installed_cmd
- name: Convert list of installed WordPress plugins from JSON
  set_fact:
    wordpress_plugin_installed_dict: '{{ wordpress_plugin_list_installed_cmd.stdout|from_json }}'
- name: Set list of installed WordPress plugins
  set_fact:
    wordpress_plugin_installed_list: '{{ wordpress_plugin_installed_dict|map(attribute="name")|list }}'
    wordpress_plugin_active_list: '{{ wordpress_plugin_installed_dict|selectattr("status", "equalto", "active")|map(attribute="name")|list }}'
- name: Install WordPress plugins
  command: 'wp plugin install "{{ item.name }}"'
  sudo_user: '{{ wordpress_user }}'
  args:
    chdir: '{{ wordpress_root }}'
  when: item.name|d() and (item.install|d(True) | bool) and item.name not in wordpress_plugin_installed_list
  ok_when: item.name|d() and (item.install|d(True) | bool) and item.name in wordpress_plugin_installed_list
  with_items: wordpress_plugins
EXPECTED RESULTS
TASK: [wordpress | Install WordPress plugins] *********************************
ok: [jessie.testing] => (item={'name': 'akismet'})
ACTUAL RESULTS
TASK: [wordpress | Install WordPress plugins] *********************************
skipping: [jessie.testing] => (item={'name': 'akismet'})
@matts-mpg
Copy link

I would love to see this feature as well. Trying to set a mysql_user play which will register ok instead of failed when the default blank password has already been changed by prior runs.

ypid added a commit to ypid/ansible-owncloud that referenced this issue Jul 9, 2016
ypid added a commit to ypid/ansible-owncloud that referenced this issue Aug 9, 2016
@ansibot ansibot added the affects_1.9 This issue/PR affects Ansible v1.9 label Sep 8, 2016
@ansibot ansibot added needs_info This issue requires further information. Please answer any outstanding questions. needs_template This issue/PR has an incomplete description. Please fill in the proposed template correctly. and removed needs_info This issue requires further information. Please answer any outstanding questions. needs_template This issue/PR has an incomplete description. Please fill in the proposed template correctly. labels Apr 4, 2017
@ansibot ansibot added the support:core This issue/PR relates to code supported by the Ansible Engineering Team. label Jun 29, 2017
@calfonso
Copy link
Contributor

calfonso commented Oct 5, 2017

We have failed_when: that you can use with a negation of the condition. Is there anything we are missing with your request that isn't solved by using failed_when?

@calfonso calfonso added the needs_info This issue requires further information. Please answer any outstanding questions. label Oct 5, 2017
@calfonso calfonso closed this as completed Oct 5, 2017
@ypid
Copy link
Contributor Author

ypid commented Oct 5, 2017

Did you read the summary 😉 ? The difference is that failed_when is evaluated after the task is run. With ok_when == True on the other hand, the task would not be run in the first place. This can come in handy when we already know that the desired state is already applied. Can you reopen?

@bcoca
Copy link
Member

bcoca commented Oct 5, 2017

ok_when == True would be the same as when: False and failed_when: False

@ypid
Copy link
Contributor Author

ypid commented Oct 5, 2017

Right, except that the task would show up as skipped where we know for a fact that it is ok.

@sivel
Copy link
Member

sivel commented Oct 5, 2017

I don't understand the argument that ok_when should run before the task. That would be inconsistent with how things like failed_when/changed_when run. I am +1 on the decision to close this ticket.

@ansibot ansibot added feature This issue/PR relates to a feature request. and removed feature_idea labels Mar 2, 2018
@gclough
Copy link

gclough commented Mar 11, 2019

@ypid , I was happy to find this... but then sad to find out it was cancelled. :-(

I too want parts of my role to show "ok" when they are skipped (because I know they are OK), rather than showing "skipped".

+1 to reopen this.

@nmiletic
Copy link

I too want parts of my role to show "ok" when they are skipped (because I know they are OK), rather than showing "skipped".

+1 to reopen this.

@ansible ansible locked and limited conversation to collaborators Apr 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affects_1.9 This issue/PR affects Ansible v1.9 feature This issue/PR relates to a feature request. needs_info This issue requires further information. Please answer any outstanding questions. support:core This issue/PR relates to code supported by the Ansible Engineering Team.
Projects
None yet
Development

No branches or pull requests

9 participants