github.com/mattyr/nomad@v0.3.3-0.20160919021406-3485a065154a/website/source/docs/commands/plan.html.md.erb (about) 1 --- 2 layout: "docs" 3 page_title: "Commands: plan" 4 sidebar_current: "docs-commands-plan" 5 description: > 6 The plan command is used to dry-run a job update to determine its effects. 7 --- 8 9 # Command: plan 10 11 The `plan` command can be used to envoke the scheduler in a dry-run mode with new 12 jobs or when updating existing jobs to determine what would happen if the job 13 is submitted. Job files must conform to the [job specification](/docs/jobspec/index.html) 14 format. 15 16 ## Usage 17 18 ``` 19 nomad plan [options] <file> 20 ``` 21 22 The plan command requires a single argument, specifying the path to a file 23 containing a [HCL job specification](/docs/jobspec/index.html). This file 24 will be read and the job checked for any problems. If the 25 supplied path is "-", the jobfile is read from STDIN. Otherwise it is read 26 from the file at the supplied path or downloaded and read from URL specified. 27 Nomad downloads jobfile using [`go-getter`](https://github.com/hashicorp/go-getter) 28 and support `go-getter` syntax. 29 30 Plan invokes a dry-run of the scheduler to determine the effects of submitting 31 either a new or updated version of a job. The plan will not result in any 32 changes to the cluster but gives insight into whether the job could be run 33 successfully and how it would affect existing allocations. 34 35 A job modify index is returned with the plan. This value can be used when 36 submitting the job using [`nomad run 37 -check-index`](/docs/commands/run.html#check-index), which will check that the 38 job was not modified between the plan and run command before invoking the 39 scheduler. This ensures the job has not been modified since the plan. 40 41 A structured diff between the local and remote job is displayed to 42 give insight into what the scheduler will attempt to do and why. 43 44 If the job has specified the region, the `-region` flag and `NOMAD_REGION` 45 environment variable are overridden and the the job's region is used. 46 47 Plan will return one of the following exit codes: 48 49 * 0: No allocations created or destroyed. 50 * 1: Allocations created or destroyed. 51 * 255: Error determining plan results. 52 53 ## General Options 54 55 <%= general_options_usage %> 56 57 ## Plan Options 58 59 * `-diff`: Determines whether the diff between the remote job and planned job is 60 shown. Defaults to true. 61 62 * `-verbose`: Increase diff verbosity. 63 64 ## Examples 65 66 Plan a new job that has not been previously submitted: 67 68 ``` 69 $ nomad run job1.nomad 70 nomad plan example.nomad 71 + Job: "example" 72 + Task Group: "cache" (1 create) 73 + Task: "redis" (forces create) 74 75 Scheduler dry-run: 76 - All tasks successfully allocated. 77 78 Job Modify Index: 0 79 To submit the job with version verification run: 80 81 nomad run -check-index 0 example.nomad 82 83 When running the job with the check-index flag, the job will only be run if the 84 server side version matches the the job modify index returned. If the index has 85 changed, another user has modified the job and the plan's results are 86 potentially invalid. 87 ``` 88 89 90 Increase the count of an existing without sufficient cluster capacity: 91 92 ``` 93 $ nomad plan example.nomad 94 +/- Job: "example" 95 +/- Task Group: "cache" (7 create, 1 in-place update) 96 +/- Count: "1" => "8" (forces create) 97 Task: "redis" 98 99 Scheduler dry-run: 100 - WARNING: Failed to place all allocations. 101 Task Group "cache" (failed to place 3 allocations): 102 * Resources exhausted on 1 nodes 103 * Dimension "cpu exhausted" exhausted on 1 nodes 104 105 Job Modify Index: 15 106 To submit the job with version verification run: 107 108 nomad run -check-index 15 example.nomad 109 110 When running the job with the check-index flag, the job will only be run if the 111 server side version matches the the job modify index returned. If the index has 112 changed, another user has modified the job and the plan's results are 113 potentially invalid. 114 ``` 115 116 Update an existing job such that it would cause a rolling update: 117 118 ``` 119 $ nomad plan example.nomad 120 +/- Job: "example" 121 +/- Task Group: "cache" (3 create/destroy update) 122 +/- Task: "redis" (forces create/destroy update) 123 +/- Config { 124 +/- image: "redis:2.8" => "redis:3.2" 125 port_map[0][db]: "6379" 126 } 127 128 Scheduler dry-run: 129 - All tasks successfully allocated. 130 - Rolling update, next evaluation will be in 10s. 131 132 Job Modify Index: 7 133 To submit the job with version verification run: 134 135 nomad run -check-index 7 example.nomad 136 137 When running the job with the check-index flag, the job will only be run if the 138 server side version matches the the job modify index returned. If the index has 139 changed, another user has modified the job and the plan's results are 140 potentially invalid. 141 ``` 142 143 Add a task to the task group using verbose mode: 144 145 ``` 146 $ nomad plan -verbose example.nomad 147 +/- Job: "example" 148 +/- Task Group: "cache" (3 create/destroy update) 149 + Task: "my-website" (forces create/destroy update) 150 + Driver: "docker" 151 + KillTimeout: "5000000000" 152 + Config { 153 + image: "node:6.2" 154 + port_map[0][web]: "80" 155 } 156 + Resources { 157 + CPU: "500" 158 + DiskMB: "300" 159 + IOPS: "0" 160 + MemoryMB: "256" 161 + Network { 162 + MBits: "10" 163 + Dynamic Port { 164 + Label: "web" 165 } 166 } 167 } 168 + LogConfig { 169 + MaxFileSizeMB: "10" 170 + MaxFiles: "10" 171 } 172 + Service { 173 + Name: "website" 174 + PortLabel: "web" 175 + Check { 176 Command: "" 177 + Interval: "10000000000" 178 + Name: "alive" 179 Path: "" 180 Protocol: "" 181 + Timeout: "2000000000" 182 + Type: "tcp" 183 } 184 } 185 Task: "redis" 186 187 Scheduler dry-run: 188 - All tasks successfully allocated. 189 - Rolling update, next evaluation will be in 10s. 190 191 Job Modify Index: 7 192 To submit the job with version verification run: 193 194 nomad run -check-index 7 example.nomad 195 196 When running the job with the check-index flag, the job will only be run if the 197 server side version matches the the job modify index returned. If the index has 198 changed, another user has modified the job and the plan's results are 199 potentially invalid. 200 ```