Roles controller support for multiple role per assignment

[nodje]

As per the README found in controller roles/roles, role which defines what role to give from a set of possible choice is a STR.
Which means that for instance, you'll need many instances of this snippet to assign multiple role to teams on organization:

controller_roles:
  - teams: X
    organization: Y
    role: auditor
  - teams: X
    organization: Y
    role: project_admin
 - teams: X
    organization: Y
    role: execute
    ....

It'd be much easier if role would support a list

Also the role description in the README mentions target_team twice but not organization, looks like a typo.

[sean-m-sullivan]

We need to add in the new fields, the awx.awx.roles module was updated a few weeks ago to allow for lists of teams and users
ansible/awx#13930

[sean-m-sullivan]

And one of the reasons why its not an entire thing of roles is because of the assigned "permision", and that each object then needs a lookup to find its appropriate permision, so it makes sense to keep it as one permision per role, but allowing multiple jt/wkflws/projects etc, for multiple teams/users still makes sense

[nodje]

I understand the reason why.
I guess, at some point, controller_configuration has to become a higher level abstraction of the underlying API and system structure and propose a contract that make sense for administration goals.

To be honest we are already seeing the limit of controller_configuration in a real world scenario (I mean our world at least!) in the sense that the content given to filetree_read is so dense for only a simple config that it's becomed hard to maintain.

To be fair we are trying to have a playbook that fully covers the initial config of a newly AAP2 setup.
Which mostly includes Settings, especially SAML, Orga, Teams, role, Inventories, schedules, of course creds and only a few project/template used to actually run user playbooks.

We were thinking that it'd be easier to be able to mix controllers into a single YML config, or folder, so as to have top level folders that represent a functional need, rather than having to slit every "functional config" into different controllers as is done now, and lose the "meaning".

Hope it makes sense, I think it'd be really helpful to mix controllers in on YML file/folder.

Also, right now, supporting multiple ENV by overriding a default config is made difficult by #558

[djdanielsson]

you may want to take a look at my example repo https://github.com/redhat-cop/aap_configuration_template/tree/repo_per_org which doesn't use filetree_read role. this does work with multiple controllers (I sort them by env). This branch shows how you can have different repo per org if you wish, if you don't care about different repo per or I would check out main branch.

[nodje]

Hey @djdanielsson, thanks for the suggestion.
It tool me a while but I finally got it. I'm not interested in the multiple repo for orgs yet, so I read the main branch.

Indeed, I think it could solve our common + env overriding settings issue.

Let me double check a couple of point, using the test env you coded.

• In controller_settings: "{{ controller_settings_all | combine(controller_settings_test, list_merge='append') }}", settings coming from controller_settings_test would override the existing settings in controller_settings_all thanks to the combine filter. Probably using the list_merge='append_rp' would be needed, I'm not too sure what happens with 'append' only when an existing setting needs to be merged.

But as for organizational purpose, that is to keel the sources more maintainable as the configuration elements grow in size and complexity, I'm not sure it'd work so well.

Here's how I think it could work. Let me know what you think please:

• to group controllers by functional group, I could define variables that contains multiple controllers, but they would need to be sourced by all controllers in group_vars/test/main.yml:

let's make an exemple:
controllers_grp_inv.yml

#Group inventories 
---
controller_template_grp_inv:
  - name: controller_config
    project: config_as_code
    job_type: run
    playbook: playbooks/controller_config.yml
    inventory: config_as_code
    execution_environment: supported
    concurrent_jobs_enabled: false
    ask_variables_on_launch: true
    limit: "{{ env }}"
    verbosity: 0
    credentials:
      - aap_admin
      - ah_token_user
      - vault
    extra_vars:
      # for debugging errors with creds change to false
      controller_configuration_credentials_secure_logging: true

controller_projects_grp_inv:
  - name: config_as_code
    description: config as code project
    organization: config_as_code
    scm_type: git
    scm_url: https://github.com/redhat-cop/aap_configuration_template.git
    scm_branch: "{{ scm_branch }}"
    scm_clean: true
    scm_update_on_launch: false
    scm_credential: ""
    update_project: true
    wait: true
...

I would then need to call this in group_vars/test/main,yml

controller_templates: "{{ controller_templates_all | combine(controller_templates_grp_inv, list_merge='append_rp') }}"
controller_projects: "{{ controller_projects_all | combine(controller_projects_grp_inv, list_merge='append_rp') }}"

I think it'd work, and allow to have all related controller in a central place.
But the main.yml in the group_var env groups would quickly become difficult to maintain.

Maybe there would be a way to create a var with the list of 'functional' controllers to call.
And the group_var env main.yml could loop over the list doing a combine on a target controller_xxxx_all

[djdanielsson]

the combine stuff I have never had an issue with how I do it, you can try and change it if you want to see if it works better for you. this is just a base template to help people get started, the idea is to give you something to work from you can modify it however you wish to. Yes it does grow to be kinda big if you have multiple orgs you could split out each org to help size wise but outside of that I do not know how to reduce the size much more, I do not think it gets much more complex though. as for your other idea, I don't think I fully understand. if you have something that would be shared across all your controllers you would put them in the all group.

[sean-m-sullivan]

Want to add on here, the multiple repos really works for when there are different teams each controlling their own space on the Automation controller. the orgs that they are in charge of. Functionally this can be one org, and it makes sense if you have 80 teams that don't overlap in a very large organization, to silo them off using one Organization per Team.

It also helps to use CI/CD to push when there are changes in different folders and using logic on that.

the Filetree Read, Templates, and even the straight configuration in the tests folders are meant to be opinionated ways to go about it. I've also seen where its one org, and 3 Controllers Dev/Staging/Prod, and those are each defined separately in their own folders, and then also where there is a generic config folder for things the same across all 3, and specific configs for things like credentials that change across environments. Just in this paragraph I've described 5 different options to use.

But like all things Ansible, there 10 different ways of doing something, and 1 solution doesn't fit all situations.

If you want to have a discussion on how to do that, that would be a good discussion for our office hours or even just a meting on its own, I think at this point, the initial issue has been resolved correct?

[nodje]

Thanks @sean-m-sullivan, yes the conversation has veered off the main topic.

I see that that the possibility of applying a role to a list of targets has been added to awx.awx collection.

I don't think it helps for my use case, but maybe I misunderstood:
My UC is having hundreds of lines of repeated roles assignation to feed filetree_read:

controller_roles:
  - teams: X
    organization: Y
    role: auditor
  - teams: X
    organization: Y
    role: project_admin
 - teams: X
    organization: Y
    role: execute
#
  - teams: XX
    organization: YY
    role: auditor
  - teams: XX
    organization: YY
    role: project_admin
 - teams: XX
    organization: YY
    role: execute
...

I'd like ideally to go for:

controller_roles:
  - teams: X
    organization: Y
    role: 
      - auditor
      - project_admin
      - execute
      - ...
  - teams: XX
    organization: YY
    role: 
      - auditor
      - project_admin
      - execute
      - ...

It could be that it includes lots of lookups behind the seen top target the proper object with the required permission.

But it'd provide be a great improvement in terms of usability.

[ivarmu]

I've already commented (late) to the PR. Maybe you can reduce code/task duplication with the following idea:

---

• hosts: localhost
  connection: local
  gather_facts: false
  vars:
  • data:
    • name: row1
      roles:
      • role1
      • role2
    • name: row2
      role: roleA
      tasks:
  • debug:
    msg:
    - "{{ item.1 if item.1 is defined else item.role }}"
    loop: "{{ (data | selectattr('role', 'defined')) + (data | subelements(['roles'], skip_missing=true)) }}"
    ...

[sean-m-sullivan]

Right now I don't see this changing, and this topic has not been updated. We've added the roles, but we shall revisit in the future, as it is limited by the API at the moment.