Closed Warkdev closed 4 years ago
The filenames are not relative to the role, but to the playbook directory. So I'm not sure why you are creating a new role...
So here's an example of how you could do this . This also shows how to use jinja templates for your mapping rules - this allows you to use jinja variables in the mapping rule , based on the inventory you are using.
Playbook:
- name: Prepare mapping rules on the Ansible host tags: ["mapping-rules"] become: "{{ ansible_use_become | default(false) }}" vars: set_mapping_rule_name: "{{ p.set_mapping_rule_name }}" template: src: "{{ p.set_mapping_rule_template_name }}" dest: "{{ p.set_mapping_rule_upload_filename }}" loop: "{{ mga_oauth_mapping_rules }}" loop_control: loop_var: p label: "Templating {{ p.set_mapping_rule_name }}" when: - mga_oauth_mapping_rules is defined - p.set_mapping_rule_template_name is defined - name: Upload mapping rule tags: ["mapping-rules"] include_role: name: set_mapping_rule vars: set_mapping_rule_name: "{{ item.set_mapping_rule_name }}" set_mapping_rule_category: "{{ item.set_mapping_rule_category }}" set_mapping_rule_upload_filename: "{{ item.set_mapping_rule_upload_filename }}" loop: "{{ mga_oauth_mapping_rules }}" loop_control: label: "Uploading {{ item.set_mapping_rule_name }} ..." when: - mga_oauth_mapping_rules is defined - item.set_mapping_rule_name is defined
In the inventory:
mga_oauth_mapping_rules:
- set_mapping_rule_name: "DEFOIDC1PostTokenGeneration" set_mapping_rule_category: "OAUTH" set_mapping_rule_template_name: "templates/mapping-rules/DEFOIDC1_post_token_generation.js" set_mapping_rule_upload_filename: "files/mapping-rules/DEFOIDC1_post_token_generation.js"
- set_mapping_rule_name: "DEFOIDC1PreTokenGeneration" set_mapping_rule_category: "OAUTH" set_mapping_rule_template_name: "templates/mapping-rules/DEFOIDC1_pre_token_generation.js" set_mapping_rule_upload_filename: "files/mapping-rules/DEFOIDC1_pre_token_generation.js"
The files/templates directories are then relative to the playbookdirectory (and because there's the usage of jinja templates, you can keep the mapping rules with the playbook and use variables to replace whatever you need replacing).
/templates/mapping-rules /files/mapping-rules
This does not answer your question, but I hope it helps nonetheless :-)
Hello Tom,
That does help from another perspective, we're making new roles as we'd like that our integration becomes standardized, leveraging our roles allows us to be more fine-grained from that perspective :)
I made it work using filename again by setting up the right path (using playbook_dir), it seems that the framework is using another relative path than the current playbook directory.
Regarding jinja template, this is interesting, we're not that far in our automation but that's definitely something I'll keep in my favorites for that time :)
Cédric Servais.
Hello,
I've checked this role but it seems that I can't get it working with the parameter "content" while it's working fine with upload_filename: https://github.com/IBM-Security/isam-ansible-roles/blob/master/set_mapping_rule/tasks/main.yml.
My role looks like:
`---
isam: appliance: "{{ inventory_hostname }}" username: "{{ username }}" password: "{{ password }}" lmi_port: "{{ lmi_port }}" log: "{{ log_level }}"
action: ibmsecurity.isam.aac.mapping_rules.set isamapi: name: "{{ set_mapping_rules_file.name }}" category: "{{ set_mapping_rules_file.category }}" filename: "{{ set_mapping_rules_file.name }}" content: "{{ lookup('file', 'vars/'+ VARS_CLUSTER +'/aac/mapping-rules/'+ set_mapping_rules_file.name + '.js') | replace('\n', '') }}"`
But doing this provide me syntax error (without the replace, I get an issue because it interprets '\n' characters). Do you have an example of a correct syntax on how to use this parameter from Ansible by loading an existing variable ?
The reason why I want to do it this way is that we've our vars stored in another location than the role and if I'm using upload_filename, I need to play with relative path and add a lot of "../../.." while I can just use vars/.. in my playbook.
Thanks,
Cédric Servais.