Allow a role to enable "become: yes" globally for the role within meta data

[memotype]

Proposal: role become

Author: Isaac Freeman IRC: twobitsprite

Date: 2018/7/5

• Status: New
• Proposal type: functionality
• Targeted Release: ?
• Associated PR: ?
• Estimated time to implement: ?

Motivation

The common use-case of having a site.yml top-level playbook that defines individual plays for individual groups, listing roles for each, can become lengthy and verbose, with quite a bit of repetition. Allowing groups to define their own list of roles within, i.e., group_vars files, or inventory sources would greatly simplify this design pattern.

Problems

What problems exist that this proposal will solve?

• Calling a role from a playbook currently requires knowledge of whether or not the role expects to be called with become: yes.
• Writing top-level playbooks in an environment with multiple contributors, or even a single contributor with a bad memory, requires deeper investigation in to roles' expectations of become.
• Top-level playbooks become long and verbose with much repetition of the 3-5 lines required to define a play just to execute a hard-coded list of roles in each play for each group.

Solution proposal

Use case: host groups can define a list of role names in their respective group_vars file, and then in a site.yml file, the user can define a generalized play like so:

- hosts: all
  become: no
  roles: "{{ group_roles | default([]) }}"

Then, within the roles/<role>/meta/main.yml file, each role could declare become: yes.

This structure allows for great encapsulation of roles so that the site.yml doesn't have to "know" whether or not each role requires become, and as a bonus, we now have a much cleaner site.yml without having to specify individual plays for each group, listing all the roles and their become status.

Dependencies (optional)

Testing (optional)

Basic unit testing to ensure the syntax and functionality works as expected should be sufficient.

Documentation (optional)

A simple entry in the roles documentation, similar to the "Role Dependencies" section would suffice.

Anything else?

[agaffney]

You can already accomplish this by doing something like the following in your role's tasks/main.yml file:

- name: block to set become=yes on all role tasks
  become: yes
  block:
    # Your role tasks under here

You may also be able to make it work by setting ansible_become: yes in your role's defaults/main.yml (I haven't tested this).

Edit: I have just tested both methods. The block method works as expected. The defaults/main.yml method also works, but the effect continues to later tasks, which is not the desired behavior.

[ssbarnea]

I find the proposal quite useful because blocks impose serious limitations themselves and it is very common for a role to need become for all its tasks.

Implementing this would clearly make roles easier to user and maintain.

[agaffney]

What limitations of blocks are you referring to? The functionality directly on blocks may be limited, but there aren't really limits on what can be done inside of them.

[memotype]

Putting everything in a role inside a block just seems like a cumbersome workaround. It exposes implementation details that should be transparent and encapsulated.

On Fri, Aug 9, 2019, 8:04 AM Andrew Gaffney notifications@github.com wrote:

What limitations of blocks are you referring to? The functionality directly on blocks may be limited, but there aren't really limits on what can be done inside of them.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ansible/proposals/issues/126?email_source=notifications&email_token=AAVFBQPVNDBOLN27CTVGSD3QDVMOTA5CNFSM4FIQ6A3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD36PE2I#issuecomment-519893609, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVFBQNVLLSNGP3X34QIG5DQDVMOTANCNFSM4FIQ6A3A .

[agaffney]

I won't disagree that it's a somewhat cumbersome workaround, but the Ansible devs probably won't implement or accept a new feature that accomplishes something you can already accomplish with a minor workaround using existing features.

[nkakouros]

There is also the option to use include_role with apply: {"become": true}.

Also, implicitly enabling become for a role seems to me a bit dangerous as not all ansible users may understand everything a role does (and they can get complicated).

Also, the first 2 problems that this proposal wants to solve are easily solved with good documentation. You mention either in the README or elsewhere that the role needs become: true.

Personally, I would vote against this.