In the following, we will take you through the steps to run end-to-end (e2e) tests for the ACK service controller for S3. You may use these steps to run e2e tests for other ACK service controllers.
If you run into any problems when testing a service controller, please raise an issue with the details so we can reproduce your issue.
For local development and testing we use "Kubernetes in Docker" (
which in turn requires Docker.
When you run the
scripts/kind-build-test.sh script the first time,
the step that builds the container image for the target ACK service
controller can take up to 40 or more minutes. This is because the container image
contains a lot of dependencies. Once you successfully build the target
image this base image layer is cached locally, and the build takes a much
shorter amount of time. We are aware of this (and the storage footprint,
ca. 3 GB) and aim to reduce both in the fullness of time.
In summary, in order to test ACK you will need to have the following tools installed and configured:
To build and test an ACK controller with
kind, execute the commands as
described in the following from the root directory of the
You should have forked this repository and
git clone'd it locally when
setting up your development environment.
Given that our test setup creates the container images and then launches a test cluster, we recommend that you have at least 4GB of RAM available for the tests.
With the prerequisites out of the way, let's move on to running e2e tests for a service controller.
Time to run the end-to-end test.
In order for the ACK service controller to manage the S3 bucket, it needs an identity. In other words, it needs an IAM role that represents the ACK service controller towards the S3 service.
First, define the name of the IAM role that will have the permission to manage S3 buckets on your behalf:
Now we need to verify the IAM principal (likely an IAM user) that is going to
assume the IAM role
ACK_TEST_IAM_ROLE. So to get its ARN, execute:
You can verify if that worked using
echo $ACK_TEST_PRINCIPAL_ARN and that should
print something along the lines of
Next up, create the IAM role, adding the necessary trust relationship to the role, using the following commands:
1 2 3 4 5 6 7 8 9 10 11 12
Using above trust policy, we can now create the IAM role:
1 2 3
Now we're in the position to give the IAM role
ACK_TEST_IAM_ROLE the permission
to handle S3 buckets for us, using:
1 2 3
Access delegation in IAM
If you're not that familiar with IAM access delegation, we recommend you to peruse the IAM documentation
Next, in order for our test to generate temporary credentials we need to tell it to use the IAM role we created in the previous step. To generate the IAM role ARN, do:
The tests uses the
generate_temp_creds function from the
scripts/lib/aws.sh script, executing effectively
aws sts assume-role --role-session-arn $AWS_ROLE_ARN --role-session-name $TEMP_ROLE
which fetches temporarily
AWS_SESSION_TOKEN used in turn to authentication the ACK
controller. The duration of the session token is 900 seconds (15 minutes).
Phew that was a lot to set up, but good news: you're almost there.
Run end-to-end test¶
Before you proceed, make sure that you've done the IAM setup in the previous step.
If you try the following command and you see an error message containing
something along the line of
AWS_ROLE_ARN is not defined. then you know
that somewhere in the IAM setup you either left out a step or one of the
Now we're finally in the position to execute the end-to-end test:
This provisions a Kubernetes cluster using
kind, builds a container image with
the ACK service controller, and loads the container image into the
It then installs the ACK service controller and related Kubernetes manifests into
kind cluster using
kustomize build | kubectl apply -f -.
Then, the above script runs a series of test scripts that call
aws CLI tools to verify that custom resources of the type managed by
the respective ACK service controller is created, updated and deleted
appropriately (still TODO).
Finally, it will run tests that create resources for the respective service and verify if the resource has successfully created. In our example case it should create an S3 bucket and then destroy it again, yielding something like the following (edited down to the relevant parts):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
As you can see, in above case the end-to-end test (creating cluster, deploying ACK, applying custom resources, and tear-down) took less than 30 seconds. This is for the warmed caches case.
Repeat for other services¶
We have end-to-end tests for all services listed in the
GA release statuses in our service listing
document. Simply replace your
SERVICE environment variable with the name of a
supported service and re-run the IAM and test steps outlined above.
We use mockery for unit testing.
You can install it by following the guideline on mockery's GitHub or simply
by running our handy script at
./scripts/install-mockery.sh for general
We track testing in the umbrella issue 6. on GitHub. Use this issue as a starting point and if you create a new testing-related issue, mention it from there.
To clean up a
kind cluster, including the container images and configuration
files created by the script specifically for said test cluster, execute:
If you want to delete all
kind cluster running on your machine, use:
With this the testing is completed. Thanks for your time and we appreciate your feedback.