23. Notifications¶

23.4.1. Email¶

The email notification type supports a wide variety of SMTP servers and has support for TLS/SSL connections.

You must provide the following details to setup an email notification:

• Host

• Recipient list

• Sender email

• Port

• Timeout (in seconds): allows you to specify up to 120 seconds, the length of time Tower may attempt connecting to the email server before giving up.

23.4.2. Grafana¶

Grafana is a fairly straightforward integration. First, create an API Key in the Grafana system (this is the token that is given to Tower).

You must provide the following details to setup a Grafana notification:

• Grafana URL: The URL of the Grafana API service, generally http://yourcompany.grafana.com.

• Grafana API Key: The user must first create an API Key in the Grafana system (this is the token that is given to Tower).

The other options of note are:

• ID of the Dashboard: When you created an API Key for the Grafana account, you can set up a dashboard with its own unique ID.

• ID of the Panel: If you added panels and graphs to your Grafana interface, you can specify its ID here.

• Tags for the Annotation: Enter keywords that help identify the type(s) of events(s) of the notification you are configuring.

• Disable SSL Verification: SSL verification is on by default, but you can choose to turn off Tower’s attempt to verify the authenticity of the target’s certificate. Environments that use internal or private CA’s should select this option to disable verification.

23.4.3. HipChat¶

There are several ways to integrate with HipChat. The Tower implementation uses HipChat “Integrations”. Currently you can find this at the bottom right of the main HipChat webview. From there, you will select “Build your own Integration”. After creating that, it will list the auth_token that needs to be supplied to Tower. Some other relevant details on the fields required by Tower for HipChat notifications:

• Destination Channels: Channels which should receive the notification (“engineering” or “#support”, for example).

• Token: The token listed after building your own HipChat integration.

• API URL: The URL of the Hipchat API service. If you create a team hosted by them it will be something like: https://team.hipchat.com. For a self-hosted integration, use a base URL similar to https://hipchat.yourcompany.com/ and add in appropriate Destination Channels without the # leading them (“engineering” rather than “#engineering”).

• Notification Label: Along with the integration name itself this will put another label on the notification (which could be helpful if multiple services are using the same integration to distinguish them from each other).

• Notification Color: This will highlight the message as the given color. If set to something HipChat does not expect, then the notification will generate an error in the given color.

• Notify Channel (optional): Selecting this will cause the bot to “notify” channel members. Normally it will just be stuck as a message in the chat channel without triggering anyone’s notifications. This option will notify users of the channel respecting their existing notification settings (browser notification, email fallback, etc.).

23.4.4. IRC¶

The Tower IRC notification takes the form of an IRC bot that will connect, deliver its messages to channel(s) or individual user(s), and then disconnect. The Tower notification bot also supports SSL authentication. The Tower bot does not currently support Nickserv identification. If a channel or user does not exist or is not on-line then the Notification will not fail; the failure scenario is reserved specifically for connectivity.

Connectivity information is straightforward:

• IRC Server Password (optional): IRC servers can require a password to connect. If the server does not require one, leave blank

• IRC Server Port: The IRC server Port

• IRC Server Address: The host name or address of the IRC server

• IRC Nick: The bot’s nickname once it connects to the server

• Destination Channels or Users: A list of users and/or channels to which to send the notification.

• SSL Connection (optional): Should the bot use SSL when connecting

23.4.5. Mattermost¶

The Mattermost notification type in Ansible Tower provides a simple interface to Mattermost’s messaging and collaboration workspace. The parameters that can be specified are:

• Target URL (required): The full URL that will be POSTed to

• Username

• Channel

• Icon URL: specifies the icon to display for this notification

• Disable SSL Verification: Turns off Tower’s attempt to verify the authenticity of the target’s certificate. Environments that use internal or private CA’s should select this option to disable verification.

23.4.6. PagerDuty¶

PagerDuty is a fairly straightforward integration. First, create an API Key in the PagerDuty system (this is the token that is given to Tower) and then create a “Service” which provides an “Integration Key” that will also be given to Tower. The other required options are:

• API Token: The user must first create an API Key in the PagerDuty system (this is the token that is given to Tower).

• PagerDuty Subdomain: When you sign up for the PagerDuty account, you receive a unique subdomain to communicate with. For instance, if you signed up as “towertest”, the web dashboard will be at towertest.pagerduty.com and you will give the Tower API towertest as the subdomain (not the full domain).

• API Service/Integration Key

• Client Identifier: This will be sent along with the alert content to the pagerduty service to help identify the service that is using the api key/service. This is helpful if multiple integrations are using the same API key and service.

23.4.7. Rocket.Chat¶

The Rocket.Chat notification type in Ansible Tower provides an interface to Rocket.Chat’s collaboration and communication platform. The parameters that can be specified are:

• Target URL (required): The full URL that will be POSTed to

• Username

• Icon URL: specifies the icon to display for this notification

• Disable SSL Verification: Turns off Tower’s attempt to verify the authenticity of the target’s certificate. Environments that use internal or private CA’s should select this option to disable verification.

23.4.8. Slack¶

Slack, a collaborative team communication and messaging tool, is pretty easy to configure.

You must supply the following to setup Slack notifications:

• A Slack app (refer to the Basic App Setup page of the Slack documentation for information on how to create one)

• A token (refer to Enabling Interactions with Bots and specific details on bot tokens on the Token Types documentation page)

Once you have a bot/app set up, you must navigate to “Your Apps”, click on the newly-created app and then go to Add features and functionality, which allows you to configure incoming webhooks, bots, and permissions; as well as Install your app to your workspace.

You must also invite the notification bot to join the channel(s) in question in Tower. Note that private messages are not supported.

23.4.9. Twilio¶

Twilio service is an Voice and SMS automation service. Once you are signed in, you must create a phone number from which the message will be sent. You can then define a “Messaging Service” under Programmable SMS and associate the number you created before with it.

Note that you may need to verify this number or some other information before you are allowed to use it to send to any numbers. The Messaging Service does not need a status callback URL nor does it need the ability to Process inbound messages.

Under your individual (or sub) account settings, you will have API credentials. Twilio uses two credentials to determine which account an API request is coming from. The “Account SID”, which acts as a username, and the “Auth Token” which acts as a password.

To setup Twilio, provide the following details:

• Account Token

• Source Phone Number (this is the number associated with the messaging service above and must be given in the form of “+15556667777”)

• Destination SMS number (this will be the list of numbers to receive the SMS and should be the 10-digit phone number)

• Account SID

23.4.10. Webhook¶

The webhook notification type in Ansible Tower provides a simple interface to sending POSTs to a predefined web service. Tower will POST to this address using application/json content type with the data payload containing all relevant details in json format. Some web service APIs expect HTTP requests to be in a certain format with certain fields. You can configure more of the webhook notification in the following ways:

• configure the HTTP method (using POST or PUT)

• body of the outgoing request

• configure authentication (using basic auth)

The parameters for configuring webhooks are:

• Username

• Basic Auth Password

• Target URL (required): The full URL to which the webhook notification will be PUT or POSTed.

• Disable SSL Verification: SSL verification is on by default, but you can choose to turn off Tower’s attempt to verify the authenticity of the target’s certificate. Environments that use internal or private CA’s should select this option to disable verification.

• HTTP Headers (required): Headers in JSON form where the keys and values are strings. For example, {"Authentication": "988881adc9fc3655077dc2d4d757d480b5ea0e11", "MessageType": "Test"}

• HTTP Method (required). Select the method for your webhook:

  • POST: Creates a new resource. Also acts as a catch-all for operations that do not fit into the other categories. It is likely you need to POST unless you know your webhook service expects a PUT.

  • PUT: Updates a specific resource (by an identifier) or a collection of resources. PUT can also be used to create a specific resource if the resource identifier is known beforehand.

job id
name
url
created_by
started
finished
status
traceback
inventory
project
playbook
credential
limit
extra_vars
hosts
http method

{"id": 38, "name": "Demo Job Template", "url": "https://towerhost/#/jobs/playbook/38", "created_by": "bianca", "started":
"2020-07-28T19:57:07.888193+00:00", "finished": null, "status": "running", "traceback": "", "inventory": "Demo Inventory",
"project": "Demo Project", "playbook": "hello_world.yml", "credential": "Demo Credential", "limit": "", "extra_vars": "{}",
"hosts": {}}POST / HTTP/1.1

job id
name
url
created_by
started
finished
status
traceback
inventory
project
playbook
credential
limit
extra_vars
hosts

{"id": 46, "name": "AWX-Collection-tests-tower_job_wait-long_running-XVFBGRSAvUUIrYKn", "url": "https://towerhost/#/jobs/playbook/46",
"created_by": "bianca", "started": "2020-07-28T20:43:36.966686+00:00", "finished": "2020-07-28T20:43:44.936072+00:00", "status": "failed",
"traceback": "", "inventory": "Demo Inventory", "project": "AWX-Collection-tests-tower_job_wait-long_running-JJSlglnwtsRJyQmw", "playbook":
"fail.yml", "credential": null, "limit": "", "extra_vars": "{\"sleep_interval\": 300}", "hosts": {"localhost": {"failed": true, "changed": 0,
"dark": 0, "failures": 1, "ok": 1, "processed": 1, "skipped": 0, "rescued": 0, "ignored": 0}}}

23.7.1. Reset the TOWER_URL_BASE¶

The primary way that Tower determines how the base URL (TOWER_URL_BASE) is defined is by looking at an incoming request and setting the server address based on that incoming request.

Tower takes settings values from the database first. If no settings values are found, Tower falls back to using the values from the settings files. If a user posts a license by navigating to the Tower host’s IP adddress, the posted license is written to the settings entry in the database.

To change the TOWER_URL_BASE if the wrong address has been picked up, navigate to the license from the Tower Settings () Menu’s License tab using the DNS entry you wish to appear in notifications, and re-add your license.