My suggestion is that this table isn’t sufficiently useful to
keep around with the combinatoric explosion of other lifecycle
phases. The logic was that someone might wonder “why isn’t my
main task starting?” and this table would show that the prestart
tasks hadn’t yet completed. One might wonder the same about
any task that has prerequisites, so should a poststart task have
a table that shows main tasks? And so on.
Since the route hierarchy guarantees that one has already passed
through a template that shows the lifecycle chart before one
can reach the template where this table is displayed, I believe
this table is redundant. It also conveys information in a more
abstract way than the chart, which is dense and more easily
understood, to me.
This handles the case where a job when from no-deployment to deployment
with canaries.
Consider a case where a `max_parallel=0` job is submitted as version 0,
then an update is submitted with `max_parallel=1, canary=1` as verion 1.
In this case, we will have 1 canary alloc, and all remaining allocs will
be version 0. Until the deployment is promoted, we ought to replace the
canaries with version 0 job (which isn't associated with a deployment).
This continues #8455 by adding accessibility audits to component integration
tests and fixing associated errors. It adds audits to existing tests rather than
adding separate ones to facilitate auditing the various permutations a
component’s rendering can go through.
It also adds linting to ensure audits happen in component tests. This
necessitated consolidating test files that were scattered.
The Olivier Poitrey Go CORS handler through 1.3.0 actively converts
a wildcard CORS policy into reflecting an arbitrary Origin header
value, which is incompatible with the CORS security design, and
could lead to CORS misconfiguration security problems.
CVE-2018-20744
Signed-off-by: Yoan Blanc <yoan@dosimple.ch>
This PR adds initial support for running Consul Connect Ingress Gateways (CIGs) in Nomad. These gateways are declared as part of a task group level service definition within the connect stanza.
```hcl
service {
connect {
gateway {
proxy {
// envoy proxy configuration
}
ingress {
// ingress-gateway configuration entry
}
}
}
}
```
A gateway can be run in `bridge` or `host` networking mode, with the caveat that host networking necessitates manually specifying the Envoy admin listener (which cannot be disabled) via the service port value.
Currently Envoy is the only supported gateway implementation in Consul, and Nomad only supports running Envoy as a gateway using the docker driver.
Aims to address #8294 and tangentially #8647
This changeset moves the installation of Nomad binaries out of the
provisioning framework and into scripts that are installed on the remote host
during AMI builds.
This provides a few advantages:
* The provisioning framework can be reduced in scope (with the goal of moving
most of it into the Terraform stack entirely).
* The scripts can be arbitrarily complex if we don't have to stuff them into
ssh commands, so it's easier to make them idempotent. In this changeset, the
scripts check the version of the existing binary and don't re-download when
using the `--nomad_sha` or `--nomad_version` flags.
* The scripts can be OS/distro specific, which helps in building new test
targets.
