Configs and Workloads in AgnosticD often need to save or return information during provisioning. Some examples include dynamically generated hostnames, IP addresses, and passwords. This information may be text messages to be delivered by email or structured data to be consumed by automation.
The agnosticd_user_info
action plugin can be used to provide to save messages and data within your config playbook, workload, or anywhere you have an Ansible task.
This replaces the previous conventions of using debug
with user.info:
messages.
To return a message to show to the lab provisioner, set msg
. For example:
- name: Report URL for web console agnosticd_user_info: msg: "OpenShift Web Console: {{ _openshift_console_url }}
To set messages on several lines then call agnosticd_user_info
with loop
.
Multiline messages cannot be passed as a text block with embedded linebreaks due to how these messages are processed by current automation.
- name: Provide OpenShift Access Information agnosticd_user_info: msg: "{{ item }}" loop: - "OpenShift Web Console: {{ _openshift_console_url }}" - "OpenShift API for command line 'oc' client: {{ _openshift_api_url }}"
Blank lines may be included in your message output by sending an empty message string.
- name: Provide OpenShift Access Information agnosticd_user_info: msg: "{{ item }}" loop: - "OpenShift Web Console: {{ _openshift_console_url }}" - "OpenShift API for command line 'oc' client: {{ _openshift_api_url }}" - "" - "You may download the 'oc' client from {{ ocp4_client_url }}"
User info messages are meant to be delivered by automation to users of the provisioned environments.
A body
may be specified in the same way as msg
to override a standard message.
Content for body
should precede other messages if provided.
- name: Provide user info message body agnosticd_user_info: body: "{{ item }}" loop: - "Your catalog item has been provisioned." - "" - "Important information about your environment:"
Messages sent this way will be saved to user-info.yaml
in the output directory, set by output_dir
.
To set data to be consumed by other automation, such as the Babylon Events UI/Bookbag, set data
when calling agnosticd_user_info
.
- name: OpenShift Access Data agnosticd_user_info: data: openshift_console_url: "{{ _openshift_console_url }}" openshift_api_url: "{{ _openshift_api_url }}"
Data values are saved as a dictionary to user-data.yaml
in the output directory.
To use this data through bookbag Asciidoc deployed by the Babylon Events UI we recommend setting AsciiDoc macros:
:openshift_console_url: %openshift_console_url% :openshift_api_url: %openshift_api_url% OpenShift Web Console: {openshift_console_url} OpenShift API: {openshift_api_url}
When provisioning a multi-user environment with AgnosticD you will want to deliver separate messages to each user. For example, a secure unique password for each user, a separate OpenShift namespace per user, etc.
User messages and data are set similarly to environment messages and data, but adding a user
argument to agnosticd_user_info
:
- name: OpenShift Access Data agnosticd_user_info: user: "user-{{ n }}" msg: |- OpenShift Web Console: {{ _openshift_console_url }} OpenShift API: {{ openshift_api_url }} Login with user "user-{{ n }}" and password "{{ _openshift_user_password[n] }}" data: openshift_console_url: "{{ _openshift_console_url }}" openshift_api_url: "{{ _openshift_api_url }}" openshift_user_name: "user-{{ n }}" openshift_user_password: "{{ _openshift_user_password[n] }}" openshift_user_namespace: "user-{{ n }}" loop: "{{ range(user_count | int) | list }}" loop_control: loop_var: n
Messages set with msg
may be multi-line when combined with user
.
This makes it easier to loop over a range of users.
If msg
is called repeatedly for the same user
then messages will be joined with a newline character.
User data
dictionary values are combined with any values previously set for the same user.
If the same key is set twice for a user then the previous value is replaced.
Environment data, set by calls to agnosticd_user_info
without user
will not be exposed to users.
All user data and messages is collected in user-data.yaml
with user data stored as a dictionary under the key "users".