Chapter 4. Advanced configurations


As a platform administrator, you can implement advanced configurations to customize Ansible Automation Platform, including database connections, logging, caching, and gRPC server parameters.

4.1. settings.py file

As a platform administrator, you can modify the settings.py file to configure various aspects of Ansible Automation Platform, such as database connections, logging configurations, caching, and more.

There are two settings.py files; the default settings.py that is part of the codebase and must not be edited, and an override file that can be used to override the default values.

The location and management of the override settings.py file can differ based on your deployment (RPM-based, container-based installation, or operator-based installation).

4.1.1. RPM deployments

The override settings.py file in an RPM-based setup can be edited directly, and changes take effect after restarting the platform gateway service. If you choose to edit the file, be sure to use the proper syntax and values. The override settings.py file is located in the following directory:

/etc/ansible-automation-platform/gateway/settings.py
Copy to Clipboard

4.1.2. Container-based deployments

For container-based installation deployments, Ansible Automation Platform runs within containers and the settings.py file is included inside the container. However, directly editing the settings.py file in container-based installation deployments is not recommended because the settings.py file is overwritten during upgrades or new installs.

To customize settings in container-based installation deployments, you can use the extra_settings parameter to ensure that customizations persist through installer updates. For more information, see Inventory file variables in the Containerized installation guide.

4.1.3. Operator-based deployments

For operator-based installation deployments, the settings.py file is typically located inside the container, however, users cannot modify the settings.py files directly in the container because containers in Red Hat OpenShift Container Platform are read-only.

Instead, for operator-based deployments, you can modify the settings for the platform gateway using the spec.extra_settings parameter on the Ansible Automation Platform custom resource.

4.2. grpc_settings.py file

Platform administrators can use the grpc_settings.py file to define special or custom parameters for the gRPC server.

There are two gRPC settings files: the default grpc_default.py that is part of the codebase and must not be edited, and an override file that can be used to override the default values. The grpc_default.py file includes database keepalive OPTIONS to help maintain a healthy gRPC connection and prevent interruptions. If it was necessary to change these defaults, the grpc_settings.py file can be used to override values from the grpc_defauly.py file.

The location and management of the override grpc_settings.py file can differ based on your deployment (RPM-based, container-based installation or operator-based installation).

4.2.1. RPM deployments

The override grpc_settings.py file in an RPM-based setup can be edited directly, and changes take effect after restarting the gateway systemd service. If you choose to edit the file, be sure to use the proper syntax and values. The override grpc_settings.py file is located in the following directory:

/etc/ansible-automation-platform/gateway/grpc_settings.py
Copy to Clipboard

4.2.2. Impacts of modifying the grpc_settings.py file

The gRPC server is responsible for helping with authentication between the different platform services. Altering the settings in the grpc_settings.py file can significantly impact the behavior and performance of the gRPC connection, especially in terms of connection stability.

It is important to thoroughly test any changes made to the gRPC settings before deploying them to production to ensure that the gRPC server functions as expected.

4.3. Loading order of settings

The platform gateway utilizes the Dynaconf library for managing its application settings. Dynaconf follows a layered configuration approach, where settings are loaded from multiple sources in a defined order, with later sources overriding earlier ones. Ansible Automation Platform loads settings in the following sequence:

  1. Application settings.py: This file is in the application itself and defines the loading order and location of additional settings files.
  2. Application default settings: The platform loads default settings from a defaults.py file, which is part of the application itself. This file includes general configurations for both the API Server and the gRPC server.
  3. Customer override file: The /etc/ansible-automation-platform/gateway/settings.py file is automatically installed and can be used to override any configuration in defaults.py. Changes to this file affect both the API and gRPC servers.
  4. Application gRPC default settings: After the customer override file, the application loads additional default settings for the gRPC server only from the grpc_default.py file. Specifically, this file includes database OPTIONS for the gRPC server, such as the keepalive parameters.
  5. Customer gRPC override file: The file /etc/ansible-automation-platform/gateway/grpc_settings.py, if present, is loaded next and any settings contained in this file are applied only to the gRPC server.
  6. Platform override settings file: Any settings in the /etc/ansible-automation-platform/settings.py file are applied to both the gRPC server and the API server. If there are multiple Ansible Automation Platform services on a single node, items in this file are applied to all services.
  7. ENV vars: Environment variables, where you can configure certain Ansible Automation Platform settings outside of the configuration files, are loaded last. They override any previously loaded settings.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat