If you provide an invalid HTTP configuration consul will still start again instead of failing. But if you do so the build-in proxy won't be able to start which you might need for connect.
The mocks where using randomly generated `ExternalSources` this change
makes sure they are fixed so we can reliably test the values. No change
to actual UI code
Sets the code toggle on the KV edit/create page to be on by default, we figured most people probably prefer this view.
Also, previously we forced the KV toggle back to a default setting for every
time you visited a KV form page. We've now changed this so that the KV code
toggle button acts as a 'global' toggle. So whatever you set it as will
be the same for every KV for the lifetime of your 'ember session'
If we are to keep this, then consider saving this into localStorage
settings or similar, added some thoughts in comments re: this as it's very likely
to happen.
The error notification was being shown on creation of an intention. This
was as a result of #4572 and/or #4572 and has not been included in a
release.
This includes a fix, plus tests to try to prevent any further regression.
1. Addition of external source icons for services marked as such.
2. New %with-tooltip css component (wip)
3. New 'no healthcheck' icon as external sources might not have
healthchecks, also minus icon on node cards in the service detail view
4. If a service doesn't have healthchecks, we use the [Services] tabs as the
default instead of the [Health Checks] tab in the Service detail page.
5. `css-var` helper. The idea here is that it will eventually be
replaced with pure css custom properties instead of having to use JS. It
would be nice to be able to build the css variables into the JS at build
time (you'd probably still want to specify in config which variables you
wanted available in JS), but that's possible future work.
Lastly there is probably a tiny bit more testing edits here than usual,
I noticed that there was an area where the dynamic mocking wasn't
happening, it was just using the mocks from consul-api-double, the mocks
I was 'dynamically' setting happened to be the same as the ones in
consul-api-double. I've fixed this here also but it wasn't effecting
anything until actually made certain values dynamic.
When adding an auto resizing (heightwise) code editor, the
ivy-codemirror plugin seems to do this using more nested divs. This div
had a horizontal scroller but couldn't be seen on some platforms (with
hidden scrollbars). This commit makes the code editor slightly more
usable and more visually correct by removing the scroll bar in this div
to stop producing the 'split view look', yet keeping the horizontal
scroller at the bottom of the code editor for when you enter code that
is wider than the area. A max-width has also been added here to prevent
the text area from growing off the side of the page.
Another improvement to the code editor here is the addition of a nicer
color for hightlighting text selection so its at least visible.
Lastly, there was a way you could get the bottom horizontal scrollbar to overlay
the code in the editor. This makes sure there is always some space at
the bottom of the editor to make sure the code won't be obscured
1. The previously used TextEncoder/Decoder (used as a polyfill for
browsers that don't have a native version) didn't expose an encoder via
CommonJS. Use a different polyfill that exposes both a decoder and an
encoder.
2. The feature detection itself was flawed. This does a less error prone
detection that ensures native encoding/decoding where available and polyfilled
encoding/decoding where not available.
* website: initial Kubernetes section with Helm information
* website: extraConfig for clients
* website: add more helm fields
* website: document extraVolumes
* website: document Consul DNS
* website: fix typos and show example of downward API
This implements parts of RFC 7871 where Consul is acting as an authoritative name server (or forwarding resolver when recursors are configured)
If ECS opt is present in the request we will mirror it back and return a response with a scope of 0 (global) or with the same prefix length as the request (indicating its valid specifically for that subnet).
We only mirror the prefix-length (non-global) for prepared queries as those could potentially use nearness checks that could be affected by the subnet. In the future we could get more sophisticated with determining the scope bits and allow for better caching of prepared queries that don’t rely on nearness checks.
The other thing this does not do is implement the part of the ECS RFC related to originating ECS headers when acting as a intermediate DNS server (forwarding resolver). That would take a quite a bit more effort and in general provide very little value. Consul will currently forward the ECS headers between recursors and the clients transparently, we just don't originate them for non-ECS clients to get potentially more accurate "location aware" results.
This improves the checking so that if a certificate were to expire or the roots changed then we will go into a non-ready state.
This parses the x509 certificates from the TLS certificate when the leaf is set. The readyCh will be closed whenever a parseable certificate is set and the ca roots are set. This does not mean that the certificate is valid but that it has been setup and is generally valid. The Ready function will now do x509 certificate verification which will in addition to verifying the signatures with the installed CA roots will also verify the certificate isn't expired or not set to become valid in the future.
The correct way to use these functions is to wait for the ReadyWait chan to be closed and then periodically check the readiness to determine if the certificate is currently useable.
Fixes: #4578
Prior to this fix if there was an error binding to ports for the DNS servers the error would be swallowed by the gated log writer and never output. This fix propagates the DNS server errors back to the shell with a multierror.
* Implementation of Weights Data structures
Adding this datastructure will allow us to resolve the
issues #1088 and #4198
This new structure defaults to values:
```
{ Passing: 1, Warning: 0 }
```
Which means, use weight of 0 for a Service in Warning State
while use Weight 1 for a Healthy Service.
Thus it remains compatible with previous Consul versions.
* Implemented weights for DNS SRV Records
* DNS properly support agents with weight support while server does not (backwards compatibility)
* Use Warning value of Weights of 1 by default
When using DNS interface with only_passing = false, all nodes
with non-Critical healthcheck used to have a weight value of 1.
While having weight.Warning = 0 as default value, this is probably
a bad idea as it breaks ascending compatibility.
Thus, we put a default value of 1 to be consistent with existing behaviour.
* Added documentation for new weight field in service description
* Better documentation about weights as suggested by @banks
* Return weight = 1 for unknown Check states as suggested by @banks
* Fixed typo (of -> or) in error message as requested by @mkeeler
* Fixed unstable unit test TestRetryJoin
* Fixed unstable tests
* Fixed wrong Fatalf format in `testrpc/wait.go`
* Added notes regarding DNS SRV lookup limitations regarding number of instances
* Documentation fixes and clarification regarding SRV records with weights as requested by @banks
* Rephrase docs
Hans Hasselberg