It seems that blink/webkit browsers at least will leak memory when using
input[type=password] inputs. This only affects us during testing as we
'refresh' the ember app ~1000 times without actually refreshing
the browser. This means references to these HTML input elements mount
up now that every single page/test has an input[password] on it.
Following this change our memory usage during testing seems to have
reduced by as much as 75%.
During normal usage the single password element is only added to the
page once per login/logout.
* ui: Move individual component types into a single %composite-list plus
1. Removes all out separate CSS components (that match HTML components)
to favour not having those separate for the moemnt at least
2. Reuses <ConsulServiceList /> component for Terminating Gateways >
Linked Services
* ui: Tweak breadcrumb spacing for '/' separator
* Fix up the tests i.e. services per tab so we can call them all services
The ACL.GetPolicy RPC endpoint was supposed to return the “parent” policy and not always the default policy. In the case of legacy management tokens the parent policy was supposed to be “manage”. The result of us not sending this properly was that operations that required specifically a management token such as saving a snapshot would not work in secondary DCs until they were upgraded.
* testing: replace most goe/verify.Values with require.Equal
One difference between these two comparisons is that go/verify considers
nil slices/maps to be equal to empty slices/maps, where as testify/require
does not, and does not appear to provide any way to enable that behaviour.
Because of this difference some expected values were changed from empty
slices to nil slices, and some calls to verify.Values were left.
* Remove github.com/pascaldekloe/goe/verify
Reduce the number of assertion packages we use from 2 to 1
Three of the checks are temporarily disabled to limit the size of the
diff, and allow us to enable all the other checks in CI.
In a follow up we can fix the issues reported by the other checks one
at a time, and enable them.
This hook replaces lib.TranslateKeys and has a number of advantages:
1. Primarily, aliases for fields are defined on the field itself, making
the aliases much easier to maintain, and more obvious to the reader.
2. TranslateKeys translation rules are not aware of structure. It could
very easily incorrectly translate a key on one struct that was intended
to be a translation rule for a completely different struct, leading
to very hard to debug errors. The hook removes the need for the
unexpected "translation rule is an empty string to indicate stop
traversal" special case.
3. TranslateKeys attempts to duplicate a bunch of tree traversal logic
that already exists in mapstructure. Using mapstructure for traversal
removes the need to traverse the entire structure multiple times, and
makes the behaviour more obvious to the reader.
This change is being made to enable a future change of replacing
PatchSliceOfMaps. TranslateKeys sits in between PatchSliceOfMaps and
mapstructure.Decode, so it must be converted to a hook first, before
PatchSliceOfMaps can be replaced by a decode hook.
The main fix here is to always union the `primary-gateways` list with
the list of mesh gateways in the primary returned from the replicated
federation states list. This will allow any replicated (incorrect) state
to be supplemented with user-configured (correct) state in the config
file. Eventually the game of random selection whack-a-mole will pick a
winning entry and re-replicate the latest federation states from the
primary. If the user-configured state is actually the incorrect one,
then the same eventual correct selection process will work in that case,
too.
The secondary fix is actually to finish making wanfed-via-mgws actually
work as originally designed. Once a secondary datacenter has replicated
federation states for the primary AND managed to stand up its own local
mesh gateways then all of the RPCs from a secondary to the primary
SHOULD go through two sets of mesh gateways to arrive in the consul
servers in the primary (one hop for the secondary datacenter's mesh
gateway, and one hop through the primary datacenter's mesh gateway).
This was neglected in the initial implementation. While everything
works, ideally we should treat communications that go around the mesh
gateways as just provided for bootstrapping purposes.
Now we heuristically use the success/failure history of the federation
state replicator goroutine loop to determine if our current mesh gateway
route is working as intended. If it is, we try using the local gateways,
and if those don't work we fall back on trying the primary via the union
of the replicated state and the go-discover configuration flags.
This can be improved slightly in the future by possibly initializing the
gateway choice to local on startup if we already have replicated state.
This PR does not address that improvement.
Fixes#7339
