Requesting Features

Relevant source files

The following files were used as context for generating this wiki page:

• .github/ISSUE_TEMPLATE/feature_request.md
• README.md
• defaults/main.yml
• meta/main.yml
• tasks/main.yml

The feature request process for the ansible-teleport role is designed to facilitate the structured expansion of the role's capabilities, ensuring that new functionalities align with the existing architecture. The project supports various Teleport services, including SSH, Application, Database, and Kubernetes services, and allows for custom configuration through Jinja2 templates.

Requests are handled via GitHub Issues using a dedicated template that prompts for problem descriptions, proposed solutions, and alternative considerations. This structured approach helps maintainers evaluate the impact on the current installation logic, configuration management, and service orchestration.

Sources: README.md:15-17, .github/ISSUE_TEMPLATE/feature_request.md

Feature Request Framework

The submission of a new feature request follows a standardized template to ensure all necessary technical context is provided. This allows the maintainers to assess how the proposed change fits into the current role structure.

Submission Requirements

When requesting a feature, users are required to provide the following information:

Section	Description
Problem Relation	Indicates if the request stems from a specific problem or limitation within the current role.
Solution Description	A clear and concise description of the desired functionality.
Alternative Considerations	Any alternative solutions or features that were considered but rejected.
Additional Context	Any other relevant information, such as specific Teleport versions or OS-specific requirements.

Sources: .github/ISSUE_TEMPLATE/feature_request.md:1-20

Feature Lifecycle Flow

The following diagram illustrates the path from a user identifying a need to the implementation within the Ansible role:

The diagram shows the transition from a user request through the review process and finally to testing and release.
Sources: .github/ISSUE_TEMPLATE/feature_request.md, README.md:21-25

Current Development Roadmap

The project maintains an active list of planned enhancements and features. These "TODO" items represent the current internal roadmap for the role.

Planned Features

• Idempotence Testing: Enhancing Molecule tests to verify that Teleport updates (binary, config, and service) are handled correctly without unnecessary changes.
• Variable Templating Tests: Adding automated verification for how variables are injected into the configuration templates.
• Container Support Investigation: Researching the utility and implementation details of running Teleport within Docker containers through this role.

Sources: README.md:21-25

Role Architecture and Extension Points

To request a feature effectively, it is necessary to understand the current extension points where new logic can be integrated. The role is divided into specific task blocks: Validations, Installation, Security, Configuration, and Service Management.

This structure defines how features should be modularized when proposed.
Sources: tasks/main.yml:4-65

Feature Compatibility

Proposed features must maintain compatibility with the existing platform support and configuration schema:

• Supported Platforms: EL (7, 8), Debian (Jessie, Stretch), and Ubuntu (Trusty, Xenial, Bionic).
• Service Integration: New features typically target the ssh_service, proxy_service, auth_service, kube_service, or db_service.

Sources: meta/main.yml:15-28, defaults/main.yml:128-195

Configuration Extensibility

The role allows for significant customization through variables, which is often the focus of feature requests. New variables are generally added to defaults/main.yml and then implemented in the relevant template or task file.

Current Service Toggles

Many features are requested as additions to the following toggleable services:

Variable	Default	Purpose
teleport_ssh_enabled	true	Controls the SSH node service.
teleport_proxy_enabled	false	Controls the Proxy service.
teleport_kube_enabled	false	Controls the Kubernetes service.
teleport_db_enabled	false	Controls the Database service.
teleport_apps_enabled	false	Controls the Application service.

Sources: defaults/main.yml:95-195

Conclusion

Requesting features in the ansible-teleport project is a structured process designed to maintain the integrity of the role while expanding its utility. By utilizing the provided GitHub issue template and aligning requests with the existing modular architecture (Validation -> Install -> Security -> Config -> Service), contributors can ensure their suggestions are technically viable and easier to implement.

Sources: .github/ISSUE_TEMPLATE/feature_request.md, tasks/main.yml:1-65