Merge consul-helm into consul-k8s #589
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
Now that we are using "v1" version of the admissionregistration.k8s.io API, the failurePolicy for the mutating webhook is "Fail" by default, where previously it was "Ignore". We need to explicitly set it to "Ignore" so that helm chart components can come up and not be rejected by the webhook.
Co-authored-by: Kyle Schochenmaier <kschoche@gmail.com>
use hashicorp docker mirror to prevent rate limit
Stop acceptance tests on first failure
* add support for using ACLs with health checks
* pass health checks flag only when enabled Co-authored-by: Luke Kysow <1034429+lkysow@users.noreply.github.com> Co-authored-by: Iryna Shustava <ishustava@users.noreply.github.com>
The check_update_interval setting controls how often Consul clients update Consul servers when the output of their checks have changed but the status hasn't. This defaults to 5m because often users would create checks that would run every minute or so and whose output contained a timestamp that would change on every iteration of the check. This would cause a lot of writes to the Consul servers even though the status of the check didn't change. In our use-case, we only update the check when the pod's readiness status changes, so we won't be spamming updates. We run into an issue though because we always set the check to failing when the pod is first created and then, because of an issue with Consul where you can't set the check output on first creation, we issue an update to the check with the same status (critical) but with output "Pod is pending". This output will take 5 minutes to show up in the UI without this setting. That might be okay if the pod immediately becomes healthy but if it doesn't then it's likely going to be confusing for users why the check is failing but it doesn't have any output. Additionally, if the pod's readiness probes fail immediately, then we'll update the output to be something like "Readiness probes failing" but again, the UI won't be updated because the status is still critical and so again the UI would show the check failing with no output.
When a user sets connectInject.envoyExtraArgs value, they can send arguments to the injected envoy sidecar binary. For example, in a development environment, we could consider enabling debug logs in all sidecars. Usage: ``` connectInject: enabled: true envoyExtraArgs: "--log-level debug --disable-hot-restart" ```
* Add field descriptions for Service Intentions CRD
* Add acceptance tests for health checks on consul-ent * update ci timeouts because of ns delete taking a while * add helper function to make tests pass
* update values file to enable health checks by default and add comments, update unit tests accordingly
* update changelog for health checks and update comments in values.yaml
* Changelog updates
Add timestamps to logs printed out by tests
Bump terratest library to the latest version to include
Break up framework package into smaller packages
* Move suite related code to the suite package
* Move config-related code to the config package
* Move test environment and test context related code to the environment package
* Move consul cluster creation code to the consul package
* Move flags to the flags package
* Move the helpers package to framework/helpers
* New logging code is all in the logger package
This is because these tests are quite similar except for the additional assertion in the health checks tests that asserts that traffic is not routed when static-server probe fails. This will save us quite a bit of run-time for both regular and *namespace tests because the bulk of the test time is taken up by the installs. This change essentially optimizes and re-uses existing installs that we already have to do to test connect.
Occasionally we see kubectl commands failing due to temporary issues connecting to the Kubernetes API. We should retry on these errors.
* Add terraform to create EKS clusters
* Update test docker image to use terraform 1.13
so that we can use "count" with terraform modules.
* Add AWS CLI to the terraform docker image
* Add a circleci job to run acceptance tests against EKS.
* Fix flakiness in mesh-gateway tests:
* the verifyFederation function would return almost immediately because consul members
are shown as alive as soon as they join. They then become unhealthy and healthy again.
This function is modified to use consul's health API to check the health of the server in the other DC.
* Make all tests use the docker mirror for the consul-k8s image so that we don't get rate-limited
In addition to running tests with a license, update the enterprise license job to not suppress error output.
* Update consul-k8s image to 0.21.0 * Update envoy image to v1.16.0
* Remove Construction Signs from Readme to fit README.md
* Fix the acceptance tests so they pass golangci-lint
Co-authored-by: Saad Jamal <saad@hashicorp.com>
Co-authored-by: Saad Jamal <saad@hashicorp.com>
New changelog entries will be for any changes to charts or the control plane, and old helm changelog entries can be referenced in the old helm repository. Co-authored-by: Saad Jamal <saad@hashicorp.com>
Co-authored-by: Saad Jamal <saad@hashicorp.com>
charts/consul. This is to make the control-plane CI work first, then, we'll update the Helm config. Co-authored-by: Saad Jamal <saad@hashicorp.com>
Co-authored-by: Saad Jamal <saad@hashicorp.com>
…ocker image Note: acceptance tests can't pass for this commit since the templates call the new binary and that's not present in the hashicorpdev/consul-k8s:latest image.
lkysow
approved these changes
Aug 5, 2021
created by control-plane code.
sadjamz
approved these changes
Aug 6, 2021
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.
Changes proposed in this PR:
consul-k8sbinary has been renamed toconsul-k8s-control-planehashicorpdev/consul-k8sfor dev images, and usehashicorpdev/consul-k8s-control-planeinsteadgithub.com/hashicorp/consul-k8stogithub.com/hashicorp/consul-k8s/control-plane.Note that when deploying the helm chart from
charts/consulthat you'll need to use an image with the new binary name, and the only image that exists now ishashicorpdev/consul-k8s-control-plane:monorepo. This will change tohashicorpdev/consul-k8s-control-plane:latestonce we push to master.How I've tested this PR:
Pipeline:
https://app.circleci.com/pipelines/github/hashicorp/consul-k8s/2309/workflows/4b6879a0-ae90-4255-a3ab-045fe7a61f43https://app.circleci.com/pipelines/github/hashicorp/consul-k8s/2310/workflows/ac15a009-aa36-48df-92a7-ac171fafdda8https://app.circleci.com/pipelines/github/hashicorp/consul-k8s/2312/workflows/1fea1fd7-b064-496c-a371-9cfad2c64af7How I expect reviewers to test this PR:
Review/pairing
If you want to check the commits more closely, this view is nicest: https://github.com/hashicorp/consul-k8s/commits/monorepo
Before merging checklist:
hashicorpdev/consul-k8s-control-plane:latestChecklist:
[ ] CHANGELOG entry added (HashiCorp engineers only, community PRs should not add a changelog entry)We can add the changelog in an upcoming PR.