In an upcoming change we will need to pass a grpc.ClientConnPool from
BaseDeps into Server. While looking at that change I noticed all of the
existing consulOption fields are already on BaseDeps.
Instead of duplicating the fields, we can create a struct used by
agent/consul, and use that struct in BaseDeps. This allows us to pass
along dependencies without translating them into different
representations.
I also looked at moving all of BaseDeps in agent/consul, however that
created some circular imports. Resolving those cycles wouldn't be too
bad (it was only an error in agent/consul being imported from
cache-types), however this change seems a little better by starting to
introduce some structure to BaseDeps.
This change is also a small step in reducing the scope of Agent.
Also remove some constants that were only used by tests, and move the
relevant comment to where the live configuration is set.
Removed some validation from NewServer and NewClient, as these are not
really runtime errors. They would be code errors, which will cause a
panic anyway, so no reason to handle them specially here.
Occasionally this test would flake. The flakes were fixed by:
1. Stopping the service and retrying to check on metrics. This way we
also include the active_streams going to 0 in the metric calls.
2. Using a reference to the global Metrics. This way when other tests
have background goroutines that are still shutting down, they won't
emit metrics to the metric instance with the fake Sink. The stats
test can patch the local reference to the global, so the existing
statHandlers will continue to emit to the global, but the stats
test will send all metrics to the replacement.
Load balancing policies are configured in service-resolvers. All Envoy load balancing algorithms are currently supported. Including: least_request, round_robin, random, maglev, and ring_hash.
At the moment hash-based load balancing configuration is not applied at mesh gateways since they cannot decrypt traffic to inspect HTTP attributes like headers.
During development a HTTP request will pause for 1 minute ONLY when an
?index is set. This gives a realistic emulation of blocking queries.
During testing we can change this latency when we are testing blocking
queries, which we do in numerous places.
A problem can arise during testing on a very slow machine.
If you are not testing blocking queries and therefore not set a latency
to test with, if the machine you are testing on is slow enough a normal
page can assert during a test, yet not tear down before a further
blocking query request is made. This blocking query then uses the default
latency which cause the page to hang for 1 minute, which in turn causes
the test to timeout.
This only seems to happen on a very slow system, but it does potentially
explain why we occasionally see the odd flakey test popping up.
* k8s > ambassador integration moved to k8s > service mesh > ambassador integration
* k8s > get started > overview moved to k8s > get started > install with
helm chart
* k8s > helm chart reference renamed to helm chart configuration
* Unignore any bin files underneath the UI folder
* Add previously ignored node exec script
* Rearrange steps file so we can continue to list steps out
Daniel Nephin