From d7861cf83e3cc1b05ff270fd67ab249042f630c3 Mon Sep 17 00:00:00 2001 From: Michael Lange Date: Wed, 2 Oct 2019 16:54:38 -0700 Subject: [PATCH] Copy changes from review --- .../web-ui/inspecting-the-cluster.html.md | 12 +++++------ .../guides/web-ui/operating-a-job.html.md | 20 +++++++------------ .../guides/web-ui/submitting-a-job.html.md | 11 +++++----- 3 files changed, 17 insertions(+), 26 deletions(-) diff --git a/website/source/guides/web-ui/inspecting-the-cluster.html.md b/website/source/guides/web-ui/inspecting-the-cluster.html.md index ad97d4db0..64beb0974 100644 --- a/website/source/guides/web-ui/inspecting-the-cluster.html.md +++ b/website/source/guides/web-ui/inspecting-the-cluster.html.md @@ -8,7 +8,7 @@ description: |- # Inspecting the Cluster -The Web UI can be a powerful tool for keeping tabs on the state of the Nomad cluster from an +The Web UI can be a powerful tool for monitoring the state of the Nomad cluster from an operator's perspective. This includes showing all client nodes, showing driver health for client nodes, driver status, resource utilization, allocations by client node, and more. @@ -110,11 +110,10 @@ details of how the drain is performed. ## Reviewing All Servers -Where client nodes are used to run your jobs, server nodes are used to run Nomad and maintain +Whereas client nodes are used to run your jobs, server nodes are used to run Nomad and maintain availability. From any page, the Servers List page can be accessed from the left-hand navbar. -Here you can see every server node. This will be a small list—typically three, but maybe five or -seven. +Here you can see every server node. This will be a small list—[typically three or five](/docs/internals/consensus.html#deployment-table). [![Servers List][img-servers-list]][img-servers-list] @@ -128,9 +127,8 @@ Clicking a server node on the Servers List will expand the tags table for the se Depending on the size of your team and the details of you Nomad deployment, you may wish to control which features different internal users have access to. This includes limiting who has access to see -and manage client nodes and see and manage server nodes. - -Nomad has an access contro list system for doing just that. +and manage client nodes and see and manage server nodes. You can enforce this with Nomad's access +control list system. By default, all features—read and write—are available to all users of the Web UI. Check out the [Securing the Web UI with ACLs](/guides/web-ui/securing.html) guide to learn how to prevent diff --git a/website/source/guides/web-ui/operating-a-job.html.md b/website/source/guides/web-ui/operating-a-job.html.md index c31ad2306..d3c79c308 100644 --- a/website/source/guides/web-ui/operating-a-job.html.md +++ b/website/source/guides/web-ui/operating-a-job.html.md @@ -10,7 +10,7 @@ description: |- The Web UI can be a powerful companion when monitoring and debugging jobs running in Nomad. The Web UI will list all jobs, link jobs to allocations, allocations to client nodes, client nodes to driver -health, and much more. This creates a fluid exploratory experience. +health, and much more. ## Reviewing All Jobs @@ -65,8 +65,7 @@ Task events are listed on the Task Detail page and live-update as Nomad handles ### Rescheduled Allocations Allocations will be placed on any client node that satisfies the constraints of the job definition. -However, just because a node sounds like a good fit doesn't mean there isn't the possibility of -unforeseen hostility, (e.g., corrupted `/bin`, no access to a container registry). +There are events, however, that will cause Nomad to reschedule allocations, (e.g., node failures). Allocations can be configured [in the job definition to reschedule](/docs/job-specification/reschedule.html) to a different client node if the allocation ends in a failed status. This will happen after the @@ -74,7 +73,7 @@ task has exhausted its [local restart attempts](/docs/job-specification/restart. The end result of this automatic procedure is a failed allocation and that failed allocation's rescheduled successor. Since Nomad handles all of this automatically, the Web UI makes sure to -explain the state of allocations through iconography and linking previous and next allocations in a +explain the state of allocations through icons and linking previous and next allocations in a reschedule chain. [![Allocation Reschedule Icon][img-alloc-reschedule-icon]][img-alloc-reschedule-icon] @@ -113,7 +112,7 @@ A task will typically emit log information to `stdout` and `stderr`. Nomad captu exposes them through an API. The Web UI uses these APIs to offer `head`, `tail`, and streaming logs from the browser. -The Web UI will first attempt to directly connecto to the client node the task is running on. +The Web UI will first attempt to directly connect to the client node the task is running on. Typically, client nodes are not accessible from the public internet. If this is the case, the Web UI will fall back and proxy to the client node from the server node with no loss of functionality. @@ -124,11 +123,7 @@ logs will still be followed using interval polling. ## Restarting or Stopping an Allocation or Task -Ideally software always runs smoothly and as intended, but this isn't something we can count on. -Sometimes tasks will have a memory leak, sometimes a node will have noisy neighbors, and sometimes -we have no clue what's going so it's time to try turning it off and on again. - -For these times, Nomad allows for restarting and stopping individual allocations and tasks. When a +Nomad allows for restarting and stopping individual allocations and tasks. When a task is restarted, Nomad will perform a local restart of the task. When an allocation is stopped, Nomad will mark the allocation as complete and perform a reschedule onto a different client node. @@ -182,9 +177,8 @@ marking them as complete, and freeing up resources in the cluster. Depending on the size of your team and the details of your Nomad deployment, you may wish to control which features different internal users have access to. This includes differentiation between -submitting jobs, restarting allocations, and viewing potentially sensitive logs. - -Nomad has an access control list system for doing just that. +submitting jobs, restarting allocations, and viewing potentially sensitive logs. You can enforce +this with Nomad's access control list system. By default, all features—read and write—are available to all users of the Web UI. Check out the [Securing the Web UI with ACLs](/guides/web-ui/securing.html) guide to learn how to prevent diff --git a/website/source/guides/web-ui/submitting-a-job.html.md b/website/source/guides/web-ui/submitting-a-job.html.md index 5c1cdadf4..bd2cb0ea0 100644 --- a/website/source/guides/web-ui/submitting-a-job.html.md +++ b/website/source/guides/web-ui/submitting-a-job.html.md @@ -76,7 +76,7 @@ Upon submitting a job, you will be redirected to the Job Overview page for the j If this is a new job, the job will start in a queued state. If there are no placement failures, allocations for the job will naturally transition from a starting to a running or failed state. Nomad is quick to schedule allocations (i.e., find a client node to start the allocation on), but an -allocation may sit in the starting state for awhile if it has to download +allocation may sit in the starting state for a while if it has to download [source images](/docs/job-specification/task.html#task-examples) or [other artifacts](/docs/job-specification/artifact.html). It may also sit in a starting state if the task fails to start and requires retry attempts. @@ -95,7 +95,7 @@ job and its allocations change. From the subnav on any job detail page, you can access the Job Definition page. The Job Definition page will show the job's underlying JSON representation. This can be useful for -quickly verifying how the job was configuring. Many properties from the job configuration will also +quickly verifying how the job was configured. Many properties from the job configuration will also be on the Job Overview page, but some deeper properties may only be available in the definition itself. It can also be convenient to see everything at once rather than traversing through task groups, allocations, and tasks. @@ -108,7 +108,7 @@ From the subnav on any job detail page, you can access the Job Versions page. The Job Versions page will show a timeline view of every version of the job. Each version in the timeline includes the version number, the time the version was submitted, whether the version is/was -stable, the number of changes, and the job diff itself. +stable, the number of changes, and the job diff. Reviewing the job diffs version by version can be used to debug issues in a similar manner to `git log`. @@ -154,9 +154,8 @@ monitor, but an experienced Nomad user can use evaluations to diagnose potential ## Access Control Depending on the size of your team and the details of your Nomad deployment, you may wish to control -which features different internal users have access to. - -Nomad has an access control list system for doing just that. +which features different internal users have access to. You can enforce this with Nomad's access +control list system. By default, all features—read and write—are available to all users of the Web UI. Check out the [Securing the Web UI with ACLs](/guides/web-ui/securing.html) guide to learn how to prevent