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

Dependency Children Skipped as Duplicates #7353

Closed
rodnaph opened this Issue May 9, 2014 · 13 comments

Comments

Projects
None yet
10 participants
@rodnaph
Copy link

rodnaph commented May 9, 2014

Issue Type:

Bug Report

Ansible Version:

master

Environment:

N/A

Summary:

If a role dependency is skipped, via:

---
dependencies:
  - { role: foo, when: false }

Then it's children are also skipped, even if they are required by other roles.

Steps To Reproduce:
# roles/foo/meta/main.yml

---
dependencies:
  - { role: child, when: false }
# roles/bar/meta/main.yml

---
dependencies:
  - { role: child }
# roles/parent/meta/main.yml

---
dependencies:
  - { role: foo }
  - { role: bar }

If the parent role is used, then child will never be executed.

Expected Results:

Roles are re-run if required by subsequent roles, and have not been run already (under no-duplicate roles policy).

Actual Results:

Role is skipped for the rest of the play.

@rodnaph rodnaph changed the title Dependecy Dependency Children Skipped as Duplicates May 9, 2014

@jimi-c jimi-c added P3 labels May 10, 2014

@mpdehaan mpdehaan added P2 and removed P3 labels May 16, 2014

@jimi-c

This comment has been minimized.

Copy link
Member

jimi-c commented May 21, 2014

Using your example, I am unable to reproduce this:

$ ansible-playbook 7353.yml 
PLAY [localhost] ************************************************************** 
TASK: [7353_child | debug msg="here i am in the child"] *********************** 
skipping: [127.0.0.1]
TASK: [7353_child | debug msg="here i am in the child"] *********************** 
ok: [127.0.0.1] => {
    "item": "", 
    "msg": "here i am in the child"
}
PLAY RECAP ******************************************************************** 
127.0.0.1                  : ok=1    changed=0    unreachable=0    failed=0   

As you can see in the above output, the child task is skipped, however it is run the second time via the dependency from the bar role.

Can you create a github repository containing a sample playbook that reliably reproduces this issue on your system and share that here so I can test against what you're seeing?

@jimi-c jimi-c added the needs_info label May 21, 2014

@rodnaph

This comment has been minimized.

Copy link

rodnaph commented May 22, 2014

Of course, here you go:

https://github.com/rodnaph/ansible-7353

@jimi-c

This comment has been minimized.

Copy link
Member

jimi-c commented May 22, 2014

Great, I do see that your roles included there do reproduce the issue. I'll look into this more today.

@stintel

This comment has been minimized.

Copy link
Contributor

stintel commented Jul 3, 2014

Having the same issue with one of my playbooks. Running git bisect shows 0411ea2 as the first bad commit. After checking later commits, I found that setting "allow_duplicates: true" in roles/child/meta/main.yml seems to solve it.

@sontek

This comment has been minimized.

Copy link

sontek commented Jul 30, 2014

+1 just had the exact same issue. Discussed on the mailing list and IRC but allow_duplicates really isn't an option for me. Slows the runs down a LOT

@msabramo

This comment has been minimized.

Copy link
Contributor

msabramo commented Jul 30, 2014

I also ran into this; I work with @sontek and it was the same playbook but I ran into a different manifestation of the problem. Basically there are 2 roles that include a role called "common" and one of the tasks in that "common" role creates a new UNIX group. One of the 2 roles that depends on the "common" role gets skipped because of a condition - that causes common to not get executed in the other role that depends on it and that role fails badly because it is relying on that group to be present (it does a chown to that user group). I managed to work around this by moving the common role up a level, but I'm pretty sure this is not possible in all situations.

I would also point out (and I can file a separate issue for this if you wish) that Ansible just says the task is skipped and gives no info about why, so it's puzzling and tricky to diagnose. If it's not feasible to have the expected behavior then please consider outputting a warning that explains why things are being skipped.

@msabramo

This comment has been minimized.

Copy link
Contributor

msabramo commented Jul 31, 2014

I looked at the code today and I don't see an easy way to solve this. Role is not a class and the building of the dependency tree is done after loading the playbook with no regard to the when clauses, those are evaluated later on. Roles seem to be a different animal than what I hoped they would be and I don't see an easy way to make them aware of what actually executed and what didn't.

Bummer.

@jimi-c

This comment has been minimized.

Copy link
Member

jimi-c commented Jul 31, 2014

@msabramo I actually have a feature branch I've been working on turn Role into a proper class, however this problem is still quite difficult to fix even in that branch.

You can find the working branch here: https://github.com/jimi-c/ansible/tree/class_based_roles

@bcoca bcoca added this to the v2 milestone Feb 11, 2015

@jimi-c jimi-c added P2 v2 and removed P3 labels Jun 22, 2015

@bcoca bcoca modified the milestone: v2 Jun 29, 2015

@bcoca bcoca removed the v2 label Jun 29, 2015

@jimi-c jimi-c closed this in 782c2f7 Jul 29, 2015

@jimi-c

This comment has been minimized.

Copy link
Member

jimi-c commented Jul 29, 2015

HI @rodnaph, the above fix actually addresses a separate bug I found while testing this in devel, but this issue should now be resolved and will be included in the next release.

If you continue seeing any problems related to this issue, or if you have any further questions, please let us know by stopping by one of the two mailing lists, as appropriate:

Because this project is very active, we're unlikely to see comments made on closed tickets, but the mailing list is a great way to ask questions, or post if you don't think this particular issue is resolved.

Thank you!

@nhooey

This comment has been minimized.

Copy link

nhooey commented May 7, 2016

@jimi-c: There appears to be a regression of this bug in between at least Ansible 2.0.0.2 and Ansible 2.0.2.0.

@jimi-c

This comment has been minimized.

Copy link
Member

jimi-c commented May 12, 2016

@nhooey I just tested this on devel, v2.0.1.0-1, and v2.0.2.0-1 and do not see the issue there.

@kevcgrant

This comment has been minimized.

Copy link

kevcgrant commented Aug 31, 2016

I am experiencing this issue on 2.1.1.0.

@jimi-c

This comment has been minimized.

Copy link
Member

jimi-c commented Sep 1, 2016

@kevcgrant please open a new issue for this, as it's probably not related to this old issue.

@ansibot ansibot added bug and removed bug_report labels Mar 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment