The nodeCheck slice was being used as the first arg in append, which in some cases will modify the array backing the slice. This would lead to service checks for other services in the wrong event.
Also refactor some things to reduce the arguments to functions.
Creating a new readTxn does not work because it will not see the newly created objects that are about to be committed. Instead use the active write Txn.
Whenever an upsert/deletion of a config entry happens, within the open
state store transaction we speculatively test compile all discovery
chains that may be affected by the pending modification to verify that
the write would not create an erroneous scenario (such as splitting
traffic to a subset that did not exist).
If a single discovery chain evaluation references two config entries
with the same kind and name in different namespaces then sometimes the
upsert/deletion would be falsely rejected. It does not appear as though
this bug would've let invalid writes through to the state store so the
correction does not require a cleanup phase.
This commit refactors the state store usage code to track unique service
name changes on transaction commit. This means we only need to lookup
usage entries when reading the information, as opposed to iterating over
a large number of service indices.
- Take into account a service instance's name being changed
- Do not iterate through entire list of service instances, we only care
about whether there is 0, 1, or more than 1.
We add a WriteTxn interface for use in updating the usage memdb table,
with the forward-looking prospect of incrementally converting other
functions to accept interfaces.
As well, we use the ReadTxn in new usage code, and as a side effect
convert a couple of existing functions to use that interface as well.
Using the newly provided state store methods, we periodically emit usage
metrics from the servers.
We decided to emit these metrics from all servers, not just the leader,
because that means we do not have to care about leader election flapping
causing metrics turbulence, and it seems reasonable for each server to
emit its own view of the state, even if they should always converge
rapidly.
- moved and renamed files/folders based on new structure
- updated docs navigation based on new structure
- moved CLI to top nav (created commands.jsx and commands-navigation.js)
- updated and added redirects
- updating to be consistent with standalone categories
- changing "overview" link in top nav to lead to where intro was moved (docs/intro)
- adding redirects for intro content
- deleting old intro folders
- format all data/navigation files
- deleting old commands folder
- reverting changes to glossary page
- adjust intro navigation for removal of 'vs' paths
- add helm page redirect
- fix more redirects
- add a missing redirect
- fix broken anchor links and formatting mistakes
- deleted duplicate section, added redirect, changed link
- removed duplicate glossary page
And into token.Store. This change isolates any awareness of token
persistence in a single place.
It is a small step in allowing Agent.New to accept its dependencies.
This test was only passing because t.Parallel was causing every subtest to run with the last value in the iteration,
which sets a value for all tokens. The test started to fail once t.Parallel was removed, but the same failure could
have been produced by adding 'tt := tt' to the t.Run() func.
These tests run in under 10ms, so there is no reason to use t.Parallel.
* Create ConsulNodeList component
* Implement ConsulNodeList and the new Search/Sort to Node List page
* Minor styling fix to align the first icons in composite row
* Fix-up and add tests for the redesigned Node List page
* Add Leader to composite row for Node List page
* Add test for node leader
The tests all run fast enough that we do not get any advantage from
using Parallel.
The one test that was slow used a long sleep. Changing the sleep to
a few milliseconds speeds up the test considerably.