Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
This PR leverages Ansible to automate cluster creation in predefined configurations. These configurations are intended to exercise ARO features in a repeatable manner. A formal proposal is under development, see
https://docs.google.com/document/d/1AIcP1jMQS-9hsI_bS6Qhr3IoqtD97LqKfw6c9PNXD5g
We have been running smoketests in regions manually. This is error-prone and needs to be automated. As a first step here is the minimum viable Ansible playbook that creates a cluster, waits for it to become healthy via kube api, runs
az aro update
, then deletes the cluster. This is designed to run Ansible from a container so that users' development hosts don't need to have Ansible installed and will facilitate running smoketests in an automated fashion in the future.This will allow us to evaluate the following questions:
Test plan for issue:
To test, make sure you've got a valid
az login
session. This is passed through to the container via your~/.azure
directory.Then run
This will first build the required aro-ansible container image if it doesn't exist, then it will execute
ansible-playbook
in the container.There are several variables implemented to control aspects of the playbook execution. These can be combined with each other as needed.
To personalize the resulting resource groups, set the
CLUSTERPREFIX
as desired. This variable defaults to your current shell's$USER
.The default region used is
eastus
. Set theREGION
parameter to choose a different region:To choose one or more cluster configurations, set the
CLUSTERPATTERN
parameter to a wildcard string that matches the cluster scenarios you wish to test:To clean up at the end of the run, set
CLEANUP
to True. This will delete the cluster, the resource group, then the Entra Service Principal and Application.Currently implemented cluster configurations are:
basic
: Simplest cluster, nothing fancyprivate
: Simple cluster with apiserver and ingress visibility set to private.enc
: Encryption-at-host enabledudr
: UserDefinedRouting with a blackhole Route Tablebyok
: Disk encryption using bring-your-own-keyPrivate clusters such as
private
andudr
will cause the creation of a jumphost to access the cluster API. Your local SSH public key will be passed to the jumphost, then ansible will use your corresponding private key to tunnel SSH through it. If your local SSH configuration differs from defaults, the Makefile supports two variables to tweak things:Is there any documentation that needs to be updated for this PR?
Yes
How do you know this will function as expected in production?