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
Create local kind cluster install #647
Conversation
@@ -2,10 +2,15 @@ kind: Cluster | |||
apiVersion: kind.x-k8s.io/v1alpha4 | |||
nodes: | |||
- role: control-plane | |||
extraPortMappings: | |||
- containerPort: 30080 | |||
hostPort: 30080 |
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.
Maybe we could benefit from having it configurable. But for now it uses a port that should not be already bound on the host. And I could not see why we'd want to change it
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.
Code overall LGTM, small comments.
However sharing concern about the use case. This helper assumes host machine is ~Unix + docker (or podman)
+ kind
installed.
For manual tests, I am not sure doing all this to wrap kind create cluster
is worth it, however it could argued that re-using manifests defined here to install some apps can be useful. In that case I'd then favor a solution that allows to re-use current in-context cluster instead (gives a lot of flexibility in the manual testing).
For E2E tests, it requires a slightly different provisioning code (hopefully environment and components are designed to have minimal changes) and it breaks the original promise: whether you run it from your laptop or from the CI, the result will be exactly the same.
I also have doubt on the iterate faster. Iterating on Kubernetes E2E usually mean provisioning once with then a lot of updates (but you're not going to update the cluster), the added provisioning time is quite short.
Once provisioned, the difference to the kubectl
user is expected to be ~0, so it'd be interesting to have a better understanding of the issues faced.
Manual testing is not the first goal of this PR, the idea was more to create a provider that provision local resources that can be used when running e2e tests locally.
Yes indeed the environment is not exactly the same as in the CI, that's one of the drawback but I tried to make the local environment as close as the remote one as possible.
It's a feedback we often have from users creating tests. Remote resources can be long to create, it often leaks some resources and running the test again can be painful (need to delete resources on AWS) and DevMode is not really helpful because the infra is not cleaned up properly between test runs
|
…ion that can be used with other local provider
Updated the PR to take into account the suggestions. I also no longer deploy the fakeintake in Kubernetes, but rather deploy it locally in Docker. As discussed with @pducolin it should make things easier to use it with other local providers |
Co-authored-by: pducolin <45568537+pducolin@users.noreply.github.com>
// The URL does not need to exist | ||
conn, err := net.Dial("udp", "8.8.8.8:80") | ||
if err != nil { | ||
log.Fatal(err) |
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.
❓ question
Should you rather return the error, instead of panicking?
/merge |
🚂 MergeQueue Pull request added to the queue. This build is going to start soon! (estimated merge in less than 24m) Use |
* Create local kind cluster install * Add API on Kubernetes Agent to be able to set environment variables * Update fakeintake env vars to be able to not use ssl * Local Fakeintake in Kubernetes * Use const for localPort * Fix lint * Do not install the fakeintake in Kubernetes, rather use a docker version that can be used with other local provider * Remove runner interface try * Remove not needed env var configuration * Remove unneeded kubeconfig modif * Remove configureEnvVars * Make linter happy * Remove AMI * Update components/datadog/fakeintake/docker.go Co-authored-by: pducolin <45568537+pducolin@users.noreply.github.com> * Update components/datadog/fakeintake/docker.go * gofmt * gomodtidy * Handle error * Use new Env interface --------- Co-authored-by: pducolin <45568537+pducolin@users.noreply.github.com>
What does this PR do?
This PR add two new components:
Kind
is installed locally30080
of the local hostThe following PR will create a local kind provider on datadog-agent: DataDog/datadog-agent#23153
The PR also creates another API to be able to set the environment variables of all the Agents deployed with helm. Otherwise this is impossible since the env variables used to configure the fakeintake override the ones provided with
WithHelmValues
Which scenarios this will impact?
Motivation
The main goal of this PR is to provide things for developers to iterate faster on their e2e tests.
Running Kubernetes tests on a remote host can be long and hard to debug, even when using
kind
Additional Notes