Add support for host-agent integration tests #400
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
NilanjanDaw
changed the title
anusha94
reviewed
Feb 25, 2022
added 7 commits
February 26, 2022 18:14
Move the agent build process to before each instead of performing it ad-hoc during container setup. This should save some time by removing redundant agent compilations
anusha94
reviewed
Feb 28, 2022
anusha94
approved these changes
Mar 2, 2022
dharmjit
approved these changes
Mar 2, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
Add support functions required for integration tests to be added for the
host-agent. The integration tests will reuse functions from the E2E tests with some refactors, which are also included here.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Partial #399
Additional information
Handle different network configurations for integration and E2E tests
The E2E tests use
kindfor deploying the management cluster and then apply cluster-template in workload cluster. In the case of the integration tests, we wanted to useenvtestinstead, just like the controller integration tests.The docker container creation helper methods were written with E2E tests in mind, so by default, they were creating containers in the
kind network. However, in our case, the management cluster runs within thehost network.One workaround was to bind the
api-serverstarted byenvtestto0.0.0.0so as to enable access from within Docker containers. However, the cert generated for theapi-serverby default is valid for localhost, and not for other addresses that we are binding to. One solution would have been to usecontroller-runtime helpersfor generating certificates for the other addresses. However, we feel that would add unnecessary complexity to the tests.Instead, we refactor the
createDockerContainer()to dynamically attach the Docker container to thehost networkfor envtest based clusters and to thekind networkfor E2E tests. This ensures that the management cluster and the hosts are in the same network.Handle redundant host-agent compilation
The
SetupByoDockerHost()was structured to always build thehost-agentbinary before setting up the docker containers. However, for tests involving multiple containers, this leads to thehost-agentbeing compiled multiple times. To remove these redundant compilations, the agent build process has been moved to the BeforeEach() function of each test and a reference for the path to the compiled binary is passed to thesetupByoDockerHost()functionSeparate Byoh docker create and exec
The
SetupByoDockerHost()has further been refactored to separate the docker creation and execution part, this would allow us to reuse the same docker container for multiple integration test cases