UI Improvement for suppressing ok from the result of job output

[sugitk]

ISSUE TYPE

• Feature Idea

SUMMARY

When a very huge job output, I would like to see only changed and failed without ok tasks.

In the upper left of the box there is a + / - icon, how about changed button or icon like that?

[donateur]

Thank you, this would be invaluable for us!

We use Ansible Tower to check/enforce configuration not only to do initial provisioning. This means there are usually hundreds of tasks for hundreds of managed nodes which do not change. Most of the time we only want to see the changes, but we sometimes also need to be able to check tasks have run.

[wenottingham]

This is what the filter is for. Example:

[donateur]

This is what the filter is for. Example:

No, just searching for "changed" fails to show the name of the task which changed, forcing you to click in to each to read it. When dealing with 10s of changes this is tedious. When there are numerous changes (out of hundreds of tasks) it can also be difficult to keep a track of which line you just clicked on for the task name.
Also searching this way completely hides all playbook load messages, which we find handy as a very brief confirmation that plays are running.

I'd like to see the proposed button show the equivalent of using "display_skipped_hosts=no" and "display_ok_hosts=no" in Engine.

EDIT: Adding clarification.

[donateur]

We deal with tens of thousands of lines of job output (even with with multiple isolated nodes splitting big jobs). As we use Ansible to enforce configuration, we'd really like to see a clear summary of what changed as, at worst, it could indicate malicious activity (insider threat). At best it's a transient problem and we need to improve some tasks.

We start with reading the PLAY RECAP and then working back to investigate at any failures, (which nodes on which tasks) then investigate any changes (which tasks, which nodes).

I don't know any way of displaying ONLY that, by default, with a search.

Showing the blue playbook load messages is a bonus (handy in Engine because you can see Ansible hasn't stalled) but I suppose not required.

[wenottingham]

I'd like to see the proposed button show the equivalent of using "display_skipped_hosts=no" and "display_ok_hosts=no" in Engine.

If this is the default behavior you'd like to see for stdout display for a particular playbook or set of them, this is best set in the ansible.cfg alongside the playbook; it will be respected by the output shown in Tower.

What tasks/hosts/etc are shown when those options are set is determined by logic embedded in the display callback itself that changes what is returned from the event (in this case, they literally return no stdout to display). To do that in Tower would be to either reimplement that logic wholesale across every job event when the button is pressed (not performant at the 10 line scale you mention), or would require the events to be augmented with some filterable field that says "in theory if this display_XXX=False was set, we wouldn't show it" (this would be an Ansible change first).

[donateur]

Thanks @wenottingham it's helpful for me to understand the complexities of what I ask.

We recently had our main repo restructured by a Red Hat consultant so that it would work with both Engine and Tower, but for reasons I don't understand tower is not reading the relevant ansible.cfg file at job time (there are multiple depending on which network the job is on which I imagine is part of the problem). I'll try a few different ways to get the default config options to change.

[donateur]

We're sill having issues with ansible.cfg not being read by tower, no matter where we try, but I'll sort those out with Red Hat.

How about this for an easier alternative:

• Add buttons to the coloured line showing successful, changed and failed tasks.

When the user clicks on any of the colours a search is added:

1. Clicking on the green bar adds a "changed:false" and "failed:false" filter (And removes any other filters)
2. Clicking on the orange bar adds a "changed:true" filter (And removes any other filters)
3. Clicking on the red bar adds a "failed:true" filter (And removes any other filters)

It's not what I would have liked originally, but it's a step in that direction and IMO makes intuitive use of the coloured status bar.

[donateur]

Thank you @wenottingham !

[AlanCoding]

We made a change somewhat recently that the shared job environment setting can be used for Ansible config settings. For this, try setting ANSIBLE_DISPLAY_SKIPPED_HOSTS to False in that. That would apply to all jobs, but as an experiment it would at least help show what's possible.

I agree that setting it via that method or ansible.cfg (top-level in the project) should be expected to take effect, because the ansible-runner callback does not call display commands on its own. If it is failing to pass config variables to its parent class, then that's probably a pretty easy fix on our side (and would reflect a bad practice).

I got interested in the problem of suppressing standard out, and went in this direction:

ansible/ansible-runner#387

That would allow swapping out the parent callback. But your settings apply to the default callback, so that's actually overkill.

So I don't know why this wouldn't work, but this comment caught my attention:

https://github.com/ansible/ansible/blob/bfd32c9b002825b4bfc0c663322fab4061702c90/lib/ansible/plugins/callback/default.py#L86

It's very strange that subclassing would make these options not work. That's very suspicious to me. I can see, maybe, if the subclass module didn't include a DOCUMENTATION string that used the default callback doc_fragment. We used to not do that, but I recently added it in. So even if you had seen this earlier this year, it's possible that it didn't work then but will start to work now.

Getting long winded here... but say I assume this works. That still wouldn't support another objective - reducing the volume of event data we're saving, because we would be saving events with empty stdout. The introduction of runner_on_start events is already kind of killing us due to this. It's a very technical / internal subject at that point, but I still think that in most cases it would be desirable to not save such events in the first place.

[AlanCoding]

Tested in the linked PR, this is working for skipped at least

[jakemcdermott]

No, just searching for "changed" fails to show the name of the task which changed, forcing you to click in to each to read it.

Hi. That would do a raw text search of the output for "changed", which isn't what you want.

changed is a field you can filter on. This is evident from taking a few moments to read the expandable key of the search filter box, which provides usage examples on field filtering as well as the currently available fields you can filter on.

You can filter down to the set of changed, failed, etc. hosts including tasks, task names, etc. by filtering on changed:true.

Does this help? cc @AlanCoding @wenottingham

---

edit: Nevermind. Perhaps I should have taken a few moments to read all of the comments on this issue.

Looks like changed and failed filtering (as well as their combinations) were already discussed with the clickable task bar suggestion here: #4092 (comment)

[AlanCoding]

From your linked comment, let me clarify:

We're sill having issues with ansible.cfg not being read by tower, no matter where we try, but I'll sort those out with Red Hat.

I believe this was fixed, as the config entry display_ok_hosts=no was mentioned. I tested this and it works. I suspect that it did not work at some time in the past, because the ansible-runner callback plugin did not extend the base documentation fragment, but it was updated due to other unrelated bugs.