+1 this is one of the issues we encountered today with @psss

While, localhost is always present implicitly, it will only match against a hosts: all pattern if it's explicitly included in the inventory. This can lead to lots of confusion and problems (such as this issue), where you need localhost to be part of the play sometimes, but not for every role/task.

The easiest way I've found to deal with this, is to not use the hosts: all pattern. Instead, for example you could do:

hosts: subjects

and

hosts: localhost

Otherwise (with hosts: all) you're often left in a lurch and need to spread ugly things like this all around:

...
    roles:
        - role: blah
          when: "inventory_hostname != 'localhost'"
...

While sometimes that has its place, it's often easier to simply separate the localhost completely in it's own play. For example:

- hosts: localhost
  ...localhost stuff...

- hosts: subjects
  ...subject stuff...

For cases where you really do want both to be part of the play, then you can explicitly mention it as the pattern:

- hosts: subjects|localhost
  ...stuff...

Hope that helps.

@bgoncalv this is still not solved in current implementation right?

not by the roles, we have some workaround on downstream where we to the provision first and make sure it worked, and just then we run the playbook.

not by the roles

This is best. Ansible is great at managing late-stage setup and configuration minutiae. Not so much for fundamental creation and bootstrapping. Use purpose-built tooling for that, like Packer & Terraform (or similar), then bring in Ansible last. i.e. after networking and basic ssh/remote access is setup.

This is also a much easier architecture to automate the testing of the frameworks themselves.