-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable e2e tests using emulators for cloud providers [ aws, gcp, azure ] #743
base: master
Are you sure you want to change the base?
Conversation
@anveshreddy18 You need rebase this pull request with latest master branch. Please check. |
|
GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
---|---|---|---|---|---|
- | RSA Private Key | 5454c29 | hack/e2e-test/infrastructure/kind/kubeconfig | View secret | |
- | RSA Private Key | dd4a097 | hack/e2e-test/infrastructure/kind/kubeconfig | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secrets safely. Learn here the best practices.
- Revoke and rotate these secrets.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the much needed PR @anveshreddy18!
I haven't taken a look at the changes in test/integrationcluster
just yet. Will take a look in a following review.
@@ -155,6 +158,9 @@ EOF | |||
} | |||
EOF | |||
export AWS_APPLICATION_CREDENTIALS_JSON="${credentials_file}" | |||
export AWS_ACCESS_KEY_ID=$1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are these variables being exported as env variables when they weren't needed to be exposed before?
The aws
cli picks up credentials from .aws
that is created in this function anyway, right?
pullPolicy: IfNotPresent | ||
# etcd-backup-restore image to use | ||
etcdBackupRestore: | ||
repository: europe-docker.pkg.dev/gardener-project/public/gardener/etcdbrctl | ||
tag: v0.12.1 | ||
tag: v0.28.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a latest
tag available for etcd-backup-restore
the way there is for etcd-druid
?
It is done that way in etcd-druid
's values.yaml
- ETCD_VERSION: optional, defaults to `v3.4.13-bootstrap-1` | ||
- ETCDBR_VERSION: optional, defaults to `v0.12.1` | ||
- ETCD_VERSION: optional, defaults to etcd-wrapper `v0.1.1` | ||
- ETCDBR_VERSION: optional, defaults to `v0.28.0` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the latest
tag is available as mentioned in this comment, this would have to be updated as well.
|
||
The e2e tests for etcd-backup-restore are the integrationcluster tests in the `test/integrationcluster` package. These tests are run on a Kubernetes cluster and test the full functionality of etcd-backup-restore. The tests create a provider namespace on the cluster and deploy the [etcd-backup-restore helm chart](../../chart/etcd-backup-restore) which in turn deploys the required secrets, configmap, services and finally the statefulset which deploys the pod that runs etcd and backup-restore as a sidecar. | ||
|
||
These tests are setup to be run with both emulators and real cloud providers. The emulators can be used for local development and testing as well as prow job to test code changes when a PR is raised. The real cloud providers can be used for testing in a real cloud environment to ensure that the changes work as expected in a real environment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't necessarily think mentioning testing through prow jobs here is relevant. But don't have a strong opinion.
make ci-e2e-kind PROVIDERS="aws,gcp" | ||
``` | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#### AWS | ||
|
||
For AWS, first get the AWS credentials and update the `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `AWS_DEFAULT_REGION` variables of the `hack/config/aws_config.sh` file with the correct values and also update the creation of `/tmp/aws.json` file with the correct values. It should look like below snippet after removing the `endpoint` and `s3ForcePathStyle` fields: | ||
|
||
```sh | ||
export AWS_APPLICATION_CREDENTIALS_JSON="/tmp/aws.json" | ||
echo "{ \"accessKeyID\": \"${AWS_ACCESS_KEY_ID}\", \"secretAccessKey\": \"${AWS_SECRET_ACCESS_KEY}\", \"region\": \"${AWS_DEFAULT_REGION}\" }" > "${AWS_APPLICATION_CREDENTIALS_JSON}" | ||
``` | ||
|
||
Apart from providing the required credentials for real provider, one should also remove the variables that signify the usage of an emulator, which are `AWS_ENDPOINT_URL_S3` and `LOCALSTACK_HOST` for Localstack. Remove them from the make command of the `hack/ci-e2e-kind.sh` script before running the tests. | ||
|
||
With these changes made, the tests can be run in the same way as with the emulators. | ||
|
||
#### GCP | ||
|
||
For GCP, first get the GCP credential service account json file and your project ID and replace the variables `GOOGLE_APPLICATION_CREDENTIALS` and `GCP_PROJECT_ID` in configuration file located at `hack/config/gcp_config.sh` with the path to this service account file and your project ID respectively. We also need to remove the environment variables for the fakegcs provider from the make command of the `hack/ci-e2e-kind.sh` file, for that one should remove the variables `GOOGLE_EMULATOR_ENABLED`, `GCS_EMULATOR_HOST` and `GOOGLE_STORAGE_API_ENDPOINT` and run the tests in the same way as with the emulators. | ||
|
||
#### Azure | ||
|
||
For Azure, first get the Azure credentials and update the `STORAGE_ACCOUNT` and `STORAGE_KEY` env variables in the configuration file located at `hack/config/azure_config.sh` with the correct values. Also, remove the variables for the azurite, which are `AZURE_STORAGE_API_ENDPOINT`, `AZURE_EMULATOR_ENABLED`, `AZURITE_HOST` and `AZURE_STORAGE_CONNECTION_STRING` from the make command of the `hack/ci-e2e-kind.sh` script. With these changes made, the tests can be run in the same way as with the emulators. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, there is no heading signifying that these paragraphs are describing running end to end tests with real infrastructure.
A sub-heading could be added, and these three sections could be nested in that.
Also, I do not agree with the recommendation of changing the hardcoded credentials for the emulators with the credentials for real infrastructure in the scripts.
It is very likely that a user would forget that they updated the emulator credentials with real credentials, and they check those credentials into their code, and push it to their remotes.
If someone wants to do it at their own risk they could, but we should not specify in the documentation that this is the recommended way of testing with real infrastructure.
/bin | ||
/hack/tools/bin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to add the /
in front of bin
and hack
?
It would be cleaner if these lines are consistent with the rest of the file where /
is not added to the beginning.
function cleanup() { | ||
if containsElement $STEPS "cleanup" || [ $cleanup_required = true ]; then | ||
kind delete cluster --name etcdbr-e2e | ||
echo "Cleaning up completed." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could the kubeconfig file that is auto generated through kind, also be removed in the cleanup?
If you think that's unnecessary then we don't need to do it.
What this PR does / why we need it:
This PR enables e2e tests ( cluster based tests ) to be run with the
emulators
of 3 major cloud providers i.e AWS, GCP, AZURE. And of course can be run with the real infra as well. The reason for using emulators is to reduce the cost of using real infra every time a PR is raised because with the enablement of e2e tests with this PR, these tests will be run as prow job for every PR.This PR also partially updates the outdated charts to reflect the changes made to the backup-restore over the years. This will help the users with setting up
backup-restore
effortlessly and also helps the developers with testingetcdbr
standaloneWhich issue(s) this PR fixes:
Fixes #722
Special notes for your reviewer:
Release note: