Before adding a new use case, make yourself familiar with the high level design process.
To create or change a use cases it is easiest to apply changes in reverse order.
Create or update the Use Case Job template in configuration-platform
NOTE: If it’s a new use case, you have to also update the projects.yml.
Each use case should have one dedicated job template following the naming convention Use Case - XYZ.
Create or update the respective use-case-xyz repository
NOTE: Use cases can do what ever they want, but should not replace or override global configuration settings defined in configuration-platform.
Make yourself familiar with the use case. If there is a HOWTO.md file in the main branch of the repository and the GitLab CI pipeline is correctly defined, documentation on how to perform the use case will automatically be rendered in the use cases section.
The use case project should contain the configuration in the format and structure recognized and supported by the infra.aap_configuration collection. Update the README.md to describe the use case, including some high level description. Also create a HOWTO.md with all necessary instructions to allow others to demonstrate the use case and any prerequisites it may have.
Typically you can add or update your use case content by rerunning the respective Job Template Use Case - XYZ from AAP.
If you create a new use case, you should als provide necessary documentation on how the use case is supposed to be executed. If there is a file named HOWTO.md it will automatically be rendered on this web site in the section use cases.
Make sure to follow this markdown formatting to render the page correctly.
# Use Case Example
Make this a level one heading.
This is an example of how use cases should be documented. Make a copy of this file, rename it to `50-my-use-case.md` and update its content.
Every use case should start with a short description. This should also include information about why this is relevant to customers, or which problem we're addressing.
## Prerequisites
Make this a level two heading.
In this chapter we document the technical requirements to demo this use case. This typically includes `extra_vars` which have to be configured, but can also include other requirements like a specific public cloud provider.
## Caveats
Make this a level two heading.
Add any potential challenges or issues in this chapter. For example certain tasks take a long time to complete, known issues or limitations.
## How to use
Make this a level two heading.
This should be a detailed list of what has to be done to demo this use case. Try to find a balance of not going to detailed, but still providing all relevant information to successfully complete the demo. This could include things like which buttons have to be clicked in the automation controller UI, or emphasis certain important points of the demo.
Keep in mind the target audience to demo the use case is SA/SSA level with at least intermediate Ansible and AAP knowledge.
*NOTE:* Any other heading should be level 2 or 3 - only this first heading should be level 1 and is used as a title.