When peering through mesh gateways we expect outbound dials to peer
servers to flow through the local mesh gateway addresses.
Now when establishing a peering we get a list of dial addresses as a
ring buffer that includes local mesh gateway addresses if the local DC
is configured to peer through mesh gateways. The ring buffer includes
the mesh gateway addresses first, but also includes the remote server
addresses as a fallback.
This fallback is present because it's possible that direct egress from
the servers may be allowed. If not allowed then the leader will cycle
back to a mesh gateway address through the ring.
When attempting to dial the remote servers we retry up to a fixed
timeout. If using mesh gateways we also have an initial wait in
order to allow for the mesh gateways to configure themselves.
Note that if we encounter a permission denied error we do not retry
since that error indicates that the secret in the peering token is
invalid.
Copy passed hash before manipulating it.
Assigning to the same hash object will break href-to
because in certain scenarios href-to-helper will
not create a new object that gets passed to
`fsm-with-optional`-hrefTo method.
This is problematic for optional route-params, and lead
to a situation where links to peered services would
create the wrong url for their href-attribute.
We need to explicitly tell the UI to not show the bucket-list
when we are displaying imported services. If we make
this depend on the data we will sometimes not show
it due to data-loader caching.
Working with a peer model as a relationship is much
easier than to workaround a non-relationship in
imported services. This is currently only relevant
for imported-services where we know the peer
in advance.
Add a helper that knows how to format past dates
in a smart way. When less than a week ago we will
use relative date strings - for dates older than a week
we will use a friendly human-readable format.
This matches best practices we want to adhere to
based on what Terraform did for date-formatting.
freddygv