Golang 1.13 is pickier with importpaths and aliasing and fails
compilation currently.
Here, for go-msgpack dependency, we use upstream ugorji/go with a single
change
23165f7bc3
.
For consistency and to ease noticing descripency, I made ugorji/go and
hashicorp/go-msgpack reference the same sha.
This is a dependency management update and has no functional change to
product.
Without passing the network isolation configuration to the executor,
java tasks are not placed in the same network namespace as the other
processes in their task group, which breaks Consul Connect.
In a job registration request, ensure that the request namespace "header" and job
namespace field match. This should be the case already in prod, as http
handlers ensures that the values match [1].
This mitigates bugs that exploit bugs where we may check a value but act
on another, resulting into bypassing ACL system.
[1] https://github.com/hashicorp/nomad/blob/v0.9.5/command/agent/job_endpoint.go#L415-L418
The recurring problem here was that sometimes the factories would
generate more than one task, and it was random whether the task
with the proxy task would be the first in the list. This ensures
that the proxy task is always first so the tests can run again.
Without a `LocalServicePort`, Connect services will try to use the
mapped port even when delivering traffic locally. A user can override
this behavior by pinning the port value in the `service` stanza but
this prevents us from using the Consul service name to reach the
service.
This commits configures the Consul proxy with its `LocalServicePort`
and `LocalServiceAddress` fields.
Fix two broken links in the Documentation & Guides section, namely Advanced Job Scheduling on Nomad with Affinities and Increasing Nomad Fault Tolerance with Spread
This fixes a race condition in the pseudo-relationship between a
TaskState and a Task that was causing the Consul Connect proxy tag
to sometimes show on the wrong task. There’s no direct Ember Data-style
relationship between a TaskState and its Task; instead, it’s determined
by searching for a Task with the matching name. The related Task was
sometimes stored before everything was ready and not recalculated when
the name became known. This ensures the relationship is accurate if the
TaskState’s name property changes.
