Merge pull request #3292 from hashicorp/f-lint-website
Spell check website
This commit is contained in:
commit
bed56cbb1e
|
@ -175,6 +175,8 @@ check: ## Lint the source code
|
|||
--enable gas \
|
||||
--enable gofmt \
|
||||
./...
|
||||
@echo "==> Spell checking website..."
|
||||
@misspell -error -source=text website/source/
|
||||
|
||||
.PHONY: checkscripts
|
||||
checkscripts: ## Lint shell scripts
|
||||
|
|
|
@ -111,7 +111,7 @@ The table below shows this endpoint's support for
|
|||
current job is at.
|
||||
|
||||
- `PolicyOverride` `(bool: false)` - If set, any soft mandatory Sentinel policies
|
||||
will be overriden. This allows a job to be registered when it would be denied
|
||||
will be overridden. This allows a job to be registered when it would be denied
|
||||
by policy.
|
||||
|
||||
### Sample Payload
|
||||
|
@ -1057,7 +1057,7 @@ The table below shows this endpoint's support for
|
|||
current job is at.
|
||||
|
||||
- `PolicyOverride` `(bool: false)` - If set, any soft mandatory Sentinel policies
|
||||
will be overriden. This allows a job to be registered when it would be denied
|
||||
will be overridden. This allows a job to be registered when it would be denied
|
||||
by policy.
|
||||
|
||||
### Sample Payload
|
||||
|
@ -1328,7 +1328,7 @@ The table below shows this endpoint's support for
|
|||
response.
|
||||
|
||||
- `PolicyOverride` `(bool: false)` - If set, any soft mandatory Sentinel policies
|
||||
will be overriden. This allows a job to be registered when it would be denied
|
||||
will be overridden. This allows a job to be registered when it would be denied
|
||||
by policy.
|
||||
|
||||
### Sample Payload
|
||||
|
|
|
@ -18,7 +18,7 @@ $ nomad run -output my-job.nomad
|
|||
|
||||
## Syntax
|
||||
|
||||
Below is the JSON representation of the job outputed by `$ nomad init`:
|
||||
Below is the JSON representation of the job outputted by `$ nomad init`:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
@ -126,7 +126,7 @@ the leader.
|
|||
|
||||
## Server Detail
|
||||
|
||||
This page lists all tags assocaited with a server.
|
||||
This page lists all tags associated with a server.
|
||||
|
||||
| Path | Produces |
|
||||
| ------------------------ | ----------- |
|
||||
|
|
|
@ -26,7 +26,7 @@ nomad job dispatch [options] <parameterized job> [input source]
|
|||
|
||||
Dispatch creates an instance of a parameterized job. A data payload to the
|
||||
dispatched instance can be provided via stdin by using "-" for the input source
|
||||
or by specifiying a path to a file. Metadata can be supplied by using the meta
|
||||
or by specifying a path to a file. Metadata can be supplied by using the meta
|
||||
flag one or more times.
|
||||
|
||||
The payload has a **size limit of 16KiB**.
|
||||
|
@ -46,9 +46,9 @@ client connection issues or internal errors, are indicated by exit code 1.
|
|||
|
||||
## Dispatch Options
|
||||
|
||||
* `-meta`: Meta takes a key/value pair seperated by "=". The metadata key will
|
||||
* `-meta`: Meta takes a key/value pair separated by "=". The metadata key will
|
||||
be merged into the job's metadata. The job may define a default value for the
|
||||
key which is overriden when dispatching. The flag can be provided more than
|
||||
key which is overridden when dispatching. The flag can be provided more than
|
||||
once to inject multiple metadata key/value pairs. Arbitrary keys are not
|
||||
allowed. The parameterized job must allow the key to be merged.
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@ description: >
|
|||
|
||||
The `job history` command is used to display the known versions of a particular
|
||||
job. The command can display the diff between job versions and can be useful for
|
||||
understanding the changes that occured to the job as well as deciding job
|
||||
understanding the changes that occurred to the job as well as deciding job
|
||||
versions to revert to.
|
||||
|
||||
## Usage
|
||||
|
|
|
@ -31,7 +31,7 @@ the given job will be chosen.
|
|||
|
||||
* `-verbose`: Display verbose output.
|
||||
|
||||
* `-job`: Use a random allocation from the specified job, prefering a running
|
||||
* `-job`: Use a random allocation from the specified job, preferring a running
|
||||
allocation.
|
||||
|
||||
* `-f`: Causes the output to not stop when the end of the logs are reached, but
|
||||
|
|
|
@ -82,7 +82,7 @@ job "docs" {
|
|||
# with Consul for service discovery and monitoring.
|
||||
service {
|
||||
# This tells Consul to monitor the service on the port
|
||||
# labled "http". Since Nomad allocates high dynamic port
|
||||
# labelled "http". Since Nomad allocates high dynamic port
|
||||
# numbers, we use labels to refer to them.
|
||||
port = "http"
|
||||
|
||||
|
|
|
@ -153,7 +153,7 @@ fail the deployment.
|
|||
### Promoting the Deployment
|
||||
|
||||
After deploying the new image along side the old version we have determined it
|
||||
is functioning properly and we want to transistion fully to the new version.
|
||||
is functioning properly and we want to transition fully to the new version.
|
||||
Doing so is as simple as promoting the deployment:
|
||||
|
||||
```text
|
||||
|
|
|
@ -24,7 +24,7 @@ Rolling updates are enabled by adding the [`update` stanza][update] to the job
|
|||
specification. The `update` stanza may be placed at the job level or in an
|
||||
individual task group. When placed at the job level, the update strategy is
|
||||
inherited by all task groups in the job. When placed at both the job and group
|
||||
level, the `update` stanzas are merged, with group stanzas taking precedance
|
||||
level, the `update` stanzas are merged, with group stanzas taking precedence
|
||||
over job level stanzas. See the [`update` stanza
|
||||
documentation](/docs/job-specification/update.html#upgrade-stanza-inheritance)
|
||||
for an example.
|
||||
|
|
|
@ -225,7 +225,7 @@ Namespace rules are keyed by the namespace name they apply to. When no namespace
|
|||
* `submit-job` - Allows jobs to be submitted or modified.
|
||||
* `read-logs` - Allows the logs associated with a job to be viewed.
|
||||
* `read-fs` - Allows the filesystem of allocations associated to be viewed.
|
||||
* `sentinel-override` - Allows soft mandatory policies to be overriden.
|
||||
* `sentinel-override` - Allows soft mandatory policies to be overridden.
|
||||
|
||||
The coarse grained policy dispositions are shorthand for the fine grained capabilities:
|
||||
|
||||
|
|
|
@ -68,13 +68,13 @@ web-qa QA instances of webservers
|
|||
### Running jobs
|
||||
|
||||
To run a job in a specific namespace, we annotate the job with the `namespace`
|
||||
parameter. If ommitted, the job will be run in the `default` namespace. Below is
|
||||
parameter. If omitted, the job will be run in the `default` namespace. Below is
|
||||
an example of running the job in the newly created `web-qa` namespace:
|
||||
|
||||
```
|
||||
job "rails-www" {
|
||||
|
||||
# Run in the QA environmet
|
||||
# Run in the QA environments
|
||||
namespace = "web-qa"
|
||||
|
||||
# Only run in one datacenter when QAing
|
||||
|
|
|
@ -15,7 +15,7 @@ insights about a cluster. It is easy to get lost in a sea of logs!
|
|||
|
||||
This guide explains how to set up configuration for Prometheus and Grafana to
|
||||
integrate with a Nomad cluster. While this introduces the basics to get a
|
||||
dashboard up and running, Nomad exposes a wide vareity of metrics, which can be
|
||||
dashboard up and running, Nomad exposes a wide variety of metrics, which can be
|
||||
explored via both Grafana and Prometheus.
|
||||
|
||||
## What metrics tools can be integrated with Nomad?
|
||||
|
|
|
@ -203,7 +203,7 @@ tls {
|
|||
}
|
||||
```
|
||||
|
||||
The file lines should point to whereever you placed the certificate files on
|
||||
The file lines should point to wherever you placed the certificate files on
|
||||
the node. This guide assumes they are in Nomad's current directory.
|
||||
|
||||
```hcl
|
||||
|
|
|
@ -23,7 +23,7 @@ Sentinel integrates with the ACL system, and provides the ability to do fine gra
|
|||
|
||||
* **Policy Scope**. Sentinel policies declare a "scope", which determines when the policies apply. Currently the only supported scope is "submit-job", which applies to any new jobs being submitted, or existing jobs being updated.
|
||||
|
||||
* **Enforcement Level**. Sentinel policies support multiple enforcement levels. The `advisory` level emits a warning when the policy fails, while `soft-mandatory` and `hard-mandatory` will prevent the operation. A `soft-mandatory` policy can be overriden if the user has necessary permissions.
|
||||
* **Enforcement Level**. Sentinel policies support multiple enforcement levels. The `advisory` level emits a warning when the policy fails, while `soft-mandatory` and `hard-mandatory` will prevent the operation. A `soft-mandatory` policy can be overridden if the user has necessary permissions.
|
||||
|
||||
### Sentinel Policies
|
||||
|
||||
|
@ -184,7 +184,7 @@ FALSE - test-policy:5:1 - Rule "all_drivers_exec"
|
|||
==> Evaluation "16195b50" finished with status "complete"
|
||||
```
|
||||
|
||||
This time, the job was accepted but with a warning that our policy is failing but was overriden.
|
||||
This time, the job was accepted but with a warning that our policy is failing but was overridden.
|
||||
|
||||
# Policy Specification
|
||||
|
||||
|
|
|
@ -11,7 +11,7 @@ description: |-
|
|||
The `job` object is made available to policies in the `submit-job` scope automatically, without an explicit import.
|
||||
The object maps to the [JSON Specification of jobs](/api/json-jobs.html), but fields differ slightly for better readability.
|
||||
|
||||
Sentinel convention for identifiers is lower case and seperated by underscores. All fields on the job are accessed by the same name, converted to lower case and seperating camal case to underscores. Here are some examples:
|
||||
Sentinel convention for identifiers is lower case and separated by underscores. All fields on the job are accessed by the same name, converted to lower case and separating camal case to underscores. Here are some examples:
|
||||
|
||||
| Job Field | Sentinel Accessor |
|
||||
| --------------------------------------- | ---------------------- |
|
||||
|
|
|
@ -41,7 +41,7 @@ description: |-
|
|||
scheduling and upgrading of the applications over time.
|
||||
</p>
|
||||
<p>
|
||||
This flexibilty makes it easy to deploy one container, dozens of
|
||||
This flexibility makes it easy to deploy one container, dozens of
|
||||
containers, or even <a
|
||||
href="https://www.hashicorp.com/c1m/">millions</a>.
|
||||
</p>
|
||||
|
|
Loading…
Reference in a new issue