--start-at-task seems broken on 2.0.0-stable

Archives Ansible Project
1

[prior post had a link in the title - if a mod can delete that post, would be great, thanks!]

I’m having some issues with ansible 2.0.0-stable (b69942a), where --start-at-task can’t find the task with that name.

I think a clue may be in --list-tasks, which doesn’t list task names for tasks defined as meta:

[output from --list-tasks]:

PLAY: #5

tasks:

TASK: meta

TASK: include tags=search,es_worker

TASK: meta

TASK: meta

When I run with --start-at-task for the last failed task from a run w/o --start-at-task, I see nothing run:

PLAY ***************************************************************************

…

PLAY RECAP *********************************************************************

[return to console]

Posting per the suggestion in this (closed) bug report, which seems to need reopening:

https://github.com/ansible/ansible/issues/11692

Has anyone else come across this?

Thanks!

2

the 'meta' tasks you see there might be the internal calls to `meta:
refresh_handlers` which don't normally have a name. List tasks in 2.0
shows these, they did not appear in previous versions.

3

Thanks Brian. I roughly binary searched and the behavior seems to have broken between Ansible code versions v1.9.4-1 and v2.0.0-0.1.alpha1.

Before, --list-tasks would show individual tasks and no ‘meta’ tasks. At 2.0, it just shows a shorter list of meta tasks, which breaks --start-at-task.

Unfortunately, that range is pretty big:

ansible (2df6513f8d802a931e0fa88afa6dc019ba4bd6e6) 14091 $ git log --pretty=oneline v1.9.4-1…v2.0.0-0.1.alpha1 | wc -l

2336

Over two thousand commits. I’ll try to bin search it, since it’s a huge pain for me to debug large Ansible runs without --start-at-task.

Brian, how should I report this to increase the chance that it gets acknowledged? It’s known broken since Jul 21:
https://github.com/ansible/ansible/issues/11692

… but I can’t reopen that bug. Should I report a new bug and link to the closed one, or can you reopen it?

Thanks,
Brandon

4

Closed bugs don’t normally get read.

If you can provide a minimally reproducible test case, we can look into it.

My tests show this feature working.

5

Brian, can you point me to the tests you’re running?

As an update to the previous, I gave up on binary searching to find where the behavior changed; the issue is present at v2.0.0-0.1.alpha1~250 but before then I see a compilation issue where Ansible thinks quotes are missing.

6

Here’s my minimal test case, which has one task.

The task comes from an include, which seems to be the issue. Yes, roles are great and we try to use them as much as possible, but our codebase has a number of places where includes are used to define tasks lists.

Brian, please let me know what to do next. Thanks.

Files (common to both versions):

[19:50:41 Mon Nov 30] brandonh@brandonh-macbook.local ~/src/fwd/ops/ansible/fwd-ubuntu

fwd-ubuntu (testing/alex/docker) 14366 $ cat site-simple.yml

7

My tests included a role and a bunch of debug tasks in 2 plays, all
worked, what did not have is a task include.

This is probably due to the new 'dynamic' nature of tasks includes in
2.0, the same reason those tasks don't appear in task lists.

8

My tests included a role and a bunch of debug tasks in 2 plays, all
worked, what did not have is a task include.

This is probably due to the new ‘dynamic’ nature of tasks includes in
2.0, the same reason those tasks don’t appear in task lists.

What do you think the correct behavior should be?

I feel like includes should get “unrolled” to enable --start-at-task. But, if you’d have to dynamically execute most of a playlist to even get to task names, I kinda see why this functionality might get forgotten.

Are you aware of any workarounds to enable debugging in the middle of a large playbook, outside of copious tags and/or commenting?

Thanks,
B

9

I think they should 'just work' TM, but this is not a simple one,
having dynamic includes makes this an 'interesting' problem, checking
with other devs trying to figure this out.

10

Thanks Brian.

Did you have a chance to talk to other devs? Is this a conversation I could join in?

We’ve now switched internally to 2.0.0 but I’m finding a lot of debugging much slower, as I have to use a mix of tags and temporary commenting-out to get playbooks working.

Thanks,
-b

11

Currently, this is the price we are paying for the dynamic 'task
includes', we are looking for ways around this issue but have not
found anything we are happy with yet.

12

–start-at-task seems to be fixed recently.

Thanks, Ansible devs! This is a major improvement to my daily workflow :slight_smile: