xpk 0.3.0__py3-none-any.whl → 0.5.0__py3-none-any.whl

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,1074 @@
1
+ Metadata-Version: 2.1
2
+ Name: xpk
3
+ Version: 0.5.0
4
+ Summary: xpk helps Cloud developers to orchestrate training jobs on accelerators on GKE.
5
+ Author-email: Cloud TPU Team <cloud-tpu-eng@google.com>
6
+ License: Apache-2.0
7
+ Project-URL: Homepage, https://github.com/google/xpk
8
+ Project-URL: Bug Tracker, https://github.com/google/xpk/issues
9
+ Classifier: Programming Language :: Python :: 3.10
10
+ Classifier: Programming Language :: Python :: 3.11
11
+ Requires-Python: >=3.10
12
+ Description-Content-Type: text/markdown
13
+ License-File: LICENSE
14
+ Requires-Dist: cloud-accelerator-diagnostics
15
+ Provides-Extra: dev
16
+ Requires-Dist: pyink ==24.3.0 ; extra == 'dev'
17
+ Requires-Dist: pylint >=2.6.0 ; extra == 'dev'
18
+ Requires-Dist: pre-commit ; extra == 'dev'
19
+
20
+ <!--
21
+ Copyright 2023 Google LLC
22
+
23
+ Licensed under the Apache License, Version 2.0 (the "License");
24
+ you may not use this file except in compliance with the License.
25
+ You may obtain a copy of the License at
26
+
27
+ https://www.apache.org/licenses/LICENSE-2.0
28
+
29
+ Unless required by applicable law or agreed to in writing, software
30
+ distributed under the License is distributed on an "AS IS" BASIS,
31
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
32
+ See the License for the specific language governing permissions and
33
+ limitations under the License.
34
+ -->
35
+
36
+ [![Build Tests](https://github.com/google/xpk/actions/workflows/build_tests.yaml/badge.svg)](https://github.com/google/xpk/actions/workflows/build_tests.yaml)
37
+ [![Nightly Tests](https://github.com/google/xpk/actions/workflows/nightly_tests.yaml/badge.svg)](https://github.com/google/xpk/actions/workflows/nightly_tests.yaml)
38
+
39
+ # Overview
40
+
41
+ xpk (Accelerated Processing Kit, pronounced x-p-k,) is a software tool to help
42
+ Cloud developers to orchestrate training jobs on accelerators such as TPUs and
43
+ GPUs on GKE. xpk handles the "multihost pods" of TPUs, GPUs (HGX H100) and CPUs
44
+ (n2-standard-32) as first class citizens.
45
+
46
+ xpk decouples provisioning capacity from running jobs. There are two structures:
47
+ clusters (provisioned VMs) and workloads (training jobs). Clusters represent the
48
+ physical resources you have available. Workloads represent training jobs -- at
49
+ any time some of these will be completed, others will be running and some will
50
+ be queued, waiting for cluster resources to become available.
51
+
52
+ The ideal workflow starts by provisioning the clusters for all of the ML
53
+ hardware you have reserved. Then, without re-provisioning, submit jobs as
54
+ needed. By eliminating the need for re-provisioning between jobs, using Docker
55
+ containers with pre-installed dependencies and cross-ahead of time compilation,
56
+ these queued jobs run with minimal start times. Further, because workloads
57
+ return the hardware back to the shared pool when they complete, developers can
58
+ achieve better use of finite hardware resources. And automated tests can run
59
+ overnight while resources tend to be underutilized.
60
+
61
+ xpk supports the following TPU types:
62
+ * v4
63
+ * v5e
64
+ * v5p
65
+
66
+ and the following GPU types:
67
+ * a100
68
+ * h100
69
+
70
+ and the following CPU types:
71
+ * n2-standard-32
72
+
73
+ # Installation
74
+ To install xpk, run the following command:
75
+
76
+ ```shell
77
+ pip install xpk
78
+ ```
79
+
80
+ If you are running XPK by cloning GitHub repository, first run the
81
+ following commands to begin using XPK commands:
82
+
83
+ ```shell
84
+ git clone https://github.com/google/xpk.git
85
+ cd xpk
86
+ # Install dependencies such as cloud-accelerator-diagnostics
87
+ pip install .
88
+ ```
89
+
90
+ If you see an error saying: `This environment is externally managed`, please use a virtual environment.
91
+
92
+ Example:
93
+
94
+ ```shell
95
+ ## One time step of creating the venv
96
+ VENV_DIR=~/venvp3
97
+ python3 -m venv $VENV_DIR
98
+ ## Enter your venv.
99
+ source $VENV_DIR/bin/activate
100
+ ## Clone the repository and installing dependencies.
101
+ git clone https://github.com/google/xpk.git
102
+ cd xpk
103
+ # Install dependencies such as cloud-accelerator-diagnostics
104
+ pip install .
105
+ ```
106
+
107
+ # XPK for Large Scale (>1k VMs)
108
+
109
+ Follow user instructions in [xpk-large-scale-guide.sh](xpk-large-scale-guide.sh)
110
+ to use xpk for a GKE cluster greater than 1000 VMs. Run these steps to set up a
111
+ GKE cluster with large scale training and high throughput support with XPK, and
112
+ run jobs with XPK. We recommend you manually copy commands per step and verify
113
+ the outputs of each step.
114
+
115
+ # Example usages:
116
+
117
+ To get started, be sure to set your GCP Project and Zone as usual via `gcloud
118
+ config set`.
119
+
120
+ Below are reference commands. A typical journey starts with a `Cluster Create`
121
+ followed by many `Workload Create`s. To understand the state of the system you
122
+ might want to use `Cluster List` or `Workload List` commands. Finally, you can
123
+ cleanup with a `Cluster Delete`.
124
+
125
+ If you have failures with workloads not running, use `xpk inspector` to investigate
126
+ more.
127
+
128
+ ## Cluster Create
129
+
130
+ First set the project and zone through gcloud config or xpk arguments.
131
+
132
+ ```shell
133
+ PROJECT_ID=my-project-id
134
+ ZONE=us-east5-b
135
+ # gcloud config:
136
+ gcloud config set project $PROJECT_ID
137
+ gcloud config set compute/zone $ZONE
138
+ # xpk arguments
139
+ xpk .. --zone $ZONE --project $PROJECT_ID
140
+ ```
141
+
142
+ The cluster created is a regional cluster to enable the GKE control plane across
143
+ all zones.
144
+
145
+ * Cluster Create (provision reserved capacity):
146
+
147
+ ```shell
148
+ # Find your reservations
149
+ gcloud compute reservations list --project=$PROJECT_ID
150
+ # Run cluster create with reservation.
151
+ python3 xpk.py cluster create \
152
+ --cluster xpk-test --tpu-type=v5litepod-256 \
153
+ --num-slices=2 \
154
+ --reservation=$RESERVATION_ID
155
+ ```
156
+
157
+ * Cluster Create (provision on-demand capacity):
158
+
159
+ ```shell
160
+ python3 xpk.py cluster create \
161
+ --cluster xpk-test --tpu-type=v5litepod-16 \
162
+ --num-slices=4 --on-demand
163
+ ```
164
+
165
+ * Cluster Create (provision spot / preemptable capacity):
166
+
167
+ ```shell
168
+ python3 xpk.py cluster create \
169
+ --cluster xpk-test --tpu-type=v5litepod-16 \
170
+ --num-slices=4 --spot
171
+ ```
172
+
173
+ * Cluster Create for Pathways:
174
+ Pathways compatible cluster can be created using `--enable-pathways`
175
+ ```shell
176
+ python3 xpk.py cluster create \
177
+ --cluster xpk-pw-test \
178
+ --num-slices=4 --on-demand \
179
+ --tpu-type=v5litepod-16 \
180
+ --enable-pathways
181
+ ```
182
+
183
+ * Cluster Create can be called again with the same `--cluster name` to modify
184
+ the number of slices or retry failed steps.
185
+
186
+ For example, if a user creates a cluster with 4 slices:
187
+
188
+ ```shell
189
+ python3 xpk.py cluster create \
190
+ --cluster xpk-test --tpu-type=v5litepod-16 \
191
+ --num-slices=4 --reservation=$RESERVATION_ID
192
+ ```
193
+
194
+ and recreates the cluster with 8 slices. The command will rerun to create 4
195
+ new slices:
196
+
197
+ ```shell
198
+ python3 xpk.py cluster create \
199
+ --cluster xpk-test --tpu-type=v5litepod-16 \
200
+ --num-slices=8 --reservation=$RESERVATION_ID
201
+ ```
202
+
203
+ and recreates the cluster with 6 slices. The command will rerun to delete 2
204
+ slices. The command will warn the user when deleting slices.
205
+ Use `--force` to skip prompts.
206
+
207
+ ```shell
208
+ python3 xpk.py cluster create \
209
+ --cluster xpk-test --tpu-type=v5litepod-16 \
210
+ --num-slices=6 --reservation=$RESERVATION_ID
211
+
212
+ # Skip delete prompts using --force.
213
+
214
+ python3 xpk.py cluster create --force \
215
+ --cluster xpk-test --tpu-type=v5litepod-16 \
216
+ --num-slices=6 --reservation=$RESERVATION_ID
217
+
218
+ ```
219
+
220
+ ### Create Vertex AI Tensorboard
221
+ *Note: This feature is available in XPK >= 0.4.0. Enable [Vertex AI API](https://cloud.google.com/vertex-ai/docs/start/cloud-environment#enable_vertexai_apis) in your Google Cloud console to use this feature. Make sure you have
222
+ [Vertex AI Administrator](https://cloud.google.com/vertex-ai/docs/general/access-control#aiplatform.admin) role
223
+ assigned to your user account.*
224
+
225
+ Vertex AI Tensorboard is a fully managed version of open-source Tensorboard. To learn more about Vertex AI Tensorboard, visit [this](https://cloud.google.com/vertex-ai/docs/experiments/tensorboard-introduction). Note that Vertex AI Tensorboard is only available in [these](https://cloud.google.com/vertex-ai/docs/general/locations#available-regions) regions.
226
+
227
+ You can create a Vertex AI Tensorboard for your cluster with `Cluster Create` command. XPK will create a single Vertex AI Tensorboard instance per cluster.
228
+
229
+ * Create Vertex AI Tensorboard in default region with default Tensorboard name:
230
+
231
+ ```shell
232
+ python3 xpk.py cluster create \
233
+ --cluster xpk-test --num-slices=1 --tpu-type=v4-8 \
234
+ --create-vertex-tensorboard
235
+ ```
236
+
237
+ will create a Vertex AI Tensorboard with the name `xpk-test-tb-instance` (*<args.cluster>-tb-instance*) in `us-central1` (*default region*).
238
+
239
+ * Create Vertex AI Tensorboard in user-specified region with default Tensorboard name:
240
+
241
+ ```shell
242
+ python3 xpk.py cluster create \
243
+ --cluster xpk-test --num-slices=1 --tpu-type=v4-8 \
244
+ --create-vertex-tensorboard --tensorboard-region=us-west1
245
+ ```
246
+
247
+ will create a Vertex AI Tensorboard with the name `xpk-test-tb-instance` (*<args.cluster>-tb-instance*) in `us-west1`.
248
+
249
+ * Create Vertex AI Tensorboard in default region with user-specified Tensorboard name:
250
+
251
+ ```shell
252
+ python3 xpk.py cluster create \
253
+ --cluster xpk-test --num-slices=1 --tpu-type=v4-8 \
254
+ --create-vertex-tensorboard --tensorboard-name=tb-testing
255
+ ```
256
+
257
+ will create a Vertex AI Tensorboard with the name `tb-testing` in `us-central1`.
258
+
259
+ * Create Vertex AI Tensorboard in user-specified region with user-specified Tensorboard name:
260
+
261
+ ```shell
262
+ python3 xpk.py cluster create \
263
+ --cluster xpk-test --num-slices=1 --tpu-type=v4-8 \
264
+ --create-vertex-tensorboard --tensorboard-region=us-west1 --tensorboard-name=tb-testing
265
+ ```
266
+
267
+ will create a Vertex AI Tensorboard instance with the name `tb-testing` in `us-west1`.
268
+
269
+ * Create Vertex AI Tensorboard in an unsupported region:
270
+
271
+ ```shell
272
+ python3 xpk.py cluster create \
273
+ --cluster xpk-test --num-slices=1 --tpu-type=v4-8 \
274
+ --create-vertex-tensorboard --tensorboard-region=us-central2
275
+ ```
276
+
277
+ will fail the cluster creation process because Vertex AI Tensorboard is not supported in `us-central2`.
278
+
279
+ ## Cluster Delete
280
+ * Cluster Delete (deprovision capacity):
281
+
282
+ ```shell
283
+ python3 xpk.py cluster delete \
284
+ --cluster xpk-test
285
+ ```
286
+ ## Cluster List
287
+ * Cluster List (see provisioned capacity):
288
+
289
+ ```shell
290
+ python3 xpk.py cluster list
291
+ ```
292
+ ## Cluster Describe
293
+ * Cluster Describe (see capacity):
294
+
295
+ ```shell
296
+ python3 xpk.py cluster describe \
297
+ --cluster xpk-test
298
+ ```
299
+
300
+ ## Cluster Cacheimage
301
+ * Cluster Cacheimage (enables faster start times):
302
+
303
+ ```shell
304
+ python3 xpk.py cluster cacheimage \
305
+ --cluster xpk-test --docker-image gcr.io/your_docker_image \
306
+ --tpu-type=v5litepod-16
307
+ ```
308
+
309
+ ## Workload Create
310
+ * Workload Create (submit training job):
311
+
312
+ ```shell
313
+ python3 xpk.py workload create \
314
+ --workload xpk-test-workload --command "echo goodbye" \
315
+ --cluster xpk-test \
316
+ --tpu-type=v5litepod-16
317
+ ```
318
+
319
+ * Workload Create for Pathways:
320
+ Pathways workload can be submitted using `--use-pathways` on a Pathways enabled cluster (created with `--enable-pathways`)
321
+
322
+ Pathways workload example:
323
+ ```shell
324
+ python3 xpk.py workload create \
325
+ --workload xpk-pw-test \
326
+ --num-slices=1 \
327
+ --tpu-type=v5litepod-16 \
328
+ --use-pathways \
329
+ --cluster xpk-pw-test \
330
+ --docker-name='user-workload' \
331
+ --docker-image=<maxtext docker image> \
332
+ --command='python3 MaxText/train.py MaxText/configs/base.yml base_output_directory=<output directory> dataset_path=<dataset path> per_device_batch_size=1 enable_checkpointing=false enable_profiler=false remat_policy=full global_parameter_scale=4 steps=300 max_target_length=2048 use_iota_embed=true reuse_example_batch=1 dataset_type=synthetic attention=flash gcs_metrics=True run_name=$(USER)-pw-xpk-test-1'
333
+ ```
334
+
335
+ Regular workload can also be submitted on a Pathways enabled cluster (created with `--enable-pathways`)
336
+
337
+ Pathways workload example:
338
+ ```shell
339
+ python3 xpk.py workload create \
340
+ --workload xpk-regular-test \
341
+ --num-slices=1 \
342
+ --tpu-type=v5litepod-16 \
343
+ --cluster xpk-pw-test \
344
+ --docker-name='user-workload' \
345
+ --docker-image=<maxtext docker image> \
346
+ --command='python3 MaxText/train.py MaxText/configs/base.yml base_output_directory=<output directory> dataset_path=<dataset path> per_device_batch_size=1 enable_checkpointing=false enable_profiler=false remat_policy=full global_parameter_scale=4 steps=300 max_target_length=2048 use_iota_embed=true reuse_example_batch=1 dataset_type=synthetic attention=flash gcs_metrics=True run_name=$(USER)-pw-xpk-test-1'
347
+ ```
348
+
349
+ ### Set `max-restarts` for production jobs
350
+
351
+ * `--max-restarts <value>`: By default, this is 0. This will restart the job ""
352
+ times when the job terminates. For production jobs, it is recommended to
353
+ increase this to a large number, say 50. Real jobs can be interrupted due to
354
+ hardware failures and software updates. We assume your job has implemented
355
+ checkpointing so the job restarts near where it was interrupted.
356
+
357
+ ### Workload Priority and Preemption
358
+ * Set the priority level of your workload with `--priority=LEVEL`
359
+
360
+ We have five priorities defined: [`very-low`, `low`, `medium`, `high`, `very-high`].
361
+ The default priority is `medium`.
362
+
363
+ Priority determines:
364
+
365
+ 1. Order of queued jobs.
366
+
367
+ Queued jobs are ordered by
368
+ `very-low` < `low` < `medium` < `high` < `very-high`
369
+
370
+ 2. Preemption of lower priority workloads.
371
+
372
+ A higher priority job will `evict` lower priority jobs.
373
+ Evicted jobs are brought back to the queue and will re-hydrate appropriately.
374
+
375
+ #### General Example:
376
+ ```shell
377
+ python3 xpk.py workload create \
378
+ --workload xpk-test-medium-workload --command "echo goodbye" --cluster \
379
+ xpk-test --tpu-type=v5litepod-16 --priority=medium
380
+ ```
381
+
382
+ ### Create Vertex AI Experiment to upload data to Vertex AI Tensorboard
383
+ *Note: This feature is available in XPK >= 0.4.0. Enable [Vertex AI API](https://cloud.google.com/vertex-ai/docs/start/cloud-environment#enable_vertexai_apis) in your Google Cloud console to use this feature. Make sure you have
384
+ [Vertex AI Administrator](https://cloud.google.com/vertex-ai/docs/general/access-control#aiplatform.admin) role
385
+ assigned to your user account and to the [Compute Engine Service account](https://cloud.google.com/compute/docs/access/service-accounts#default_service_account) attached to the node pools in the cluster.*
386
+
387
+ Vertex AI Experiment is a tool that helps to track and analyze an experiment run on Vertex AI Tensorboard. To learn more about Vertex AI Experiments, visit [this](https://cloud.google.com/vertex-ai/docs/experiments/intro-vertex-ai-experiments).
388
+
389
+ XPK will create a Vertex AI Experiment in `workload create` command and attach the Vertex AI Tensorboard created for the cluster during `cluster create`. If there is a cluster created before this feature is released, there will be no Vertex AI Tensorboard created for the cluster and `workload create` will fail. Re-run `cluster create` to create a Vertex AI Tensorboard and then run `workload create` again to schedule your workload.
390
+
391
+ * Create Vertex AI Experiment with default Experiment name:
392
+
393
+ ```shell
394
+ python3 xpk.py workload create \
395
+ --cluster xpk-test --workload xpk-workload \
396
+ --use-vertex-tensorboard
397
+ ```
398
+
399
+ will create a Vertex AI Experiment with the name `xpk-test-xpk-workload` (*<args.cluster>-<args.workload>*).
400
+
401
+ * Create Vertex AI Experiment with user-specified Experiment name:
402
+
403
+ ```shell
404
+ python3 xpk.py workload create \
405
+ --cluster xpk-test --workload xpk-workload \
406
+ --use-vertex-tensorboard --experiment-name=test-experiment
407
+ ```
408
+
409
+ will create a Vertex AI Experiment with the name `test-experiment`.
410
+
411
+ Check out [MaxText example](https://github.com/google/maxtext/pull/570) on how to update your workload to automatically upload logs collected in your Tensorboard directory to the Vertex AI Experiment created by `workload create`.
412
+
413
+ ## Workload Delete
414
+ * Workload Delete (delete training job):
415
+
416
+ ```shell
417
+ python3 xpk.py workload delete \
418
+ --workload xpk-test-workload --cluster xpk-test
419
+ ```
420
+
421
+ This will only delete `xpk-test-workload` workload in `xpk-test` cluster.
422
+
423
+ * Workload Delete (delete all training jobs in the cluster):
424
+
425
+ ```shell
426
+ python3 xpk.py workload delete \
427
+ --cluster xpk-test
428
+ ```
429
+
430
+ This will delete all the workloads in `xpk-test` cluster. Deletion will only begin if you type `y` or `yes` at the prompt. Multiple workload deletions are processed in batches for optimized processing.
431
+
432
+ * Workload Delete supports filtering. Delete a portion of jobs that match user criteria. Multiple workload deletions are processed in batches for optimized processing.
433
+ * Filter by Job: `filter-by-job`
434
+
435
+ ```shell
436
+ python3 xpk.py workload delete \
437
+ --cluster xpk-test --filter-by-job=$USER
438
+ ```
439
+
440
+ This will delete all the workloads in `xpk-test` cluster whose names start with `$USER`. Deletion will only begin if you type `y` or `yes` at the prompt.
441
+
442
+ * Filter by Status: `filter-by-status`
443
+
444
+ ```shell
445
+ python3 xpk.py workload delete \
446
+ --cluster xpk-test --filter-by-status=QUEUED
447
+ ```
448
+
449
+ This will delete all the workloads in `xpk-test` cluster that have the status as Admitted or Evicted, and the number of running VMs is 0. Deletion will only begin if you type `y` or `yes` at the prompt. Status can be: `EVERYTHING`,`FINISHED`, `RUNNING`, `QUEUED`, `FAILED`, `SUCCESSFUL`.
450
+
451
+ ## Workload List
452
+ * Workload List (see training jobs):
453
+
454
+ ```shell
455
+ python3 xpk.py workload list \
456
+ --cluster xpk-test
457
+ ```
458
+
459
+ * Example Workload List Output:
460
+
461
+ The below example shows four jobs of different statuses:
462
+
463
+ * `user-first-job-failed`: **filter-status** is `FINISHED` and `FAILED`.
464
+ * `user-second-job-success`: **filter-status** is `FINISHED` and `SUCCESSFUL`.
465
+ * `user-third-job-running`: **filter-status** is `RUNNING`.
466
+ * `user-forth-job-in-queue`: **filter-status** is `QUEUED`.
467
+ * `user-fifth-job-in-queue-preempted`: **filter-status** is `QUEUED`.
468
+
469
+ ```
470
+ Jobset Name Created Time Priority TPU VMs Needed TPU VMs Running/Ran TPU VMs Done Status Status Message Status Time
471
+ user-first-job-failed 2023-1-1T1:00:00Z medium 4 4 <none> Finished JobSet failed 2023-1-1T1:05:00Z
472
+ user-second-job-success 2023-1-1T1:10:00Z medium 4 4 4 Finished JobSet finished successfully 2023-1-1T1:14:00Z
473
+ user-third-job-running 2023-1-1T1:15:00Z medium 4 4 <none> Admitted Admitted by ClusterQueue cluster-queue 2023-1-1T1:16:00Z
474
+ user-forth-job-in-queue 2023-1-1T1:16:05Z medium 4 <none> <none> Admitted couldn't assign flavors to pod set slice-job: insufficient unused quota for google.com/tpu in flavor 2xv4-8, 4 more need 2023-1-1T1:16:10Z
475
+ user-fifth-job-preempted 2023-1-1T1:10:05Z low 4 <none> <none> Evicted Preempted to accommodate a higher priority Workload 2023-1-1T1:10:00Z
476
+ ```
477
+
478
+ * Workload List supports filtering. Observe a portion of jobs that match user criteria.
479
+
480
+ * Filter by Status: `filter-by-status`
481
+
482
+ Filter the workload list by the status of respective jobs.
483
+ Status can be: `EVERYTHING`,`FINISHED`, `RUNNING`, `QUEUED`, `FAILED`, `SUCCESSFUL`
484
+
485
+ * Filter by Job: `filter-by-job`
486
+
487
+ Filter the workload list by the name of a job.
488
+
489
+ ```shell
490
+ python3 xpk.py workload list \
491
+ --cluster xpk-test --filter-by-job=$USER
492
+ ```
493
+
494
+ * Workload List supports waiting for the completion of a specific job. XPK will follow an existing job until it has finished or the `timeout`, if provided, has been reached and then list the job. If no `timeout` is specified, the default value is set to the max value, 1 week. You may also set `timeout=0` to poll the job once.
495
+ (Note: `restart-on-user-code-failure` must be set
496
+ when creating the workload otherwise the workload will always finish with `Completed` status.)
497
+
498
+ Wait for a job to complete.
499
+
500
+ ```shell
501
+ python3 xpk.py workload list \
502
+ --cluster xpk-test --wait-for-job-completion=xpk-test-workload
503
+ ```
504
+
505
+ Wait for a job to complete with a timeout of 300 seconds.
506
+
507
+ ```shell
508
+ python3 xpk.py workload list \
509
+ --cluster xpk-test --wait-for-job-completion=xpk-test-workload \
510
+ --timeout=300
511
+ ```
512
+
513
+ Return codes
514
+ `0`: Workload finished and completed successfully.
515
+ `124`: Timeout was reached before workload finished.
516
+ `125`: Workload finished but did not complete successfully.
517
+ `1`: Other failure.
518
+
519
+ ## Inspector
520
+ * Inspector provides debug info to understand cluster health, and why workloads are not running.
521
+ Inspector output is saved to a file.
522
+
523
+ ```shell
524
+ python3 xpk.py inspector \
525
+ --cluster $CLUSTER_NAME \
526
+ --project $PROJECT_ID \
527
+ --zone $ZONE
528
+ ```
529
+
530
+ * Optional Arguments
531
+ * `--print-to-terminal`:
532
+ Print command output to terminal as well as a file.
533
+ * `--workload $WORKLOAD_NAME`
534
+ Inspector will write debug info related to the workload:`$WORKLOAD_NAME`
535
+
536
+ * Example Output:
537
+
538
+ The output of xpk inspector is in `/tmp/tmp0pd6_k1o` in this example.
539
+ ```shell
540
+ [XPK] Starting xpk
541
+ [XPK] Task: `Set Cluster` succeeded.
542
+ [XPK] Task: `Local Setup: gcloud version` is implemented by `gcloud version`, hiding output unless there is an error.
543
+ [XPK] Task: `Local Setup: Project / Zone / Region` is implemented by `gcloud config get project; gcloud config get compute/zone; gcloud config get compute/region`, hiding output unless there is an error.
544
+ [XPK] Task: `GKE: Cluster Details` is implemented by `gcloud beta container clusters list --project $PROJECT --region $REGION | grep -e NAME -e $CLUSTER_NAME`, hiding output unless there is an error.
545
+ [XPK] Task: `GKE: Node pool Details` is implemented by `gcloud beta container node-pools list --cluster $CLUSTER_NAME --project=$PROJECT --region=$REGION`, hiding output unless there is an error.
546
+ [XPK] Task: `Kubectl: All Nodes` is implemented by `kubectl get node -o custom-columns='NODE_NAME:metadata.name, READY_STATUS:.status.conditions[?(@.type=="Ready")].status, NODEPOOL:metadata.labels.cloud\.google\.com/gke-nodepool'`, hiding output unless there is an error.
547
+ [XPK] Task: `Kubectl: Number of Nodes per Node Pool` is implemented by `kubectl get node -o custom-columns=':metadata.labels.cloud\.google\.com/gke-nodepool' | sort | uniq -c`, hiding output unless there is an error.
548
+ [XPK] Task: `Kubectl: Healthy Node Count Per Node Pool` is implemented by `kubectl get node -o custom-columns='NODE_NAME:metadata.name, READY_STATUS:.status.conditions[?(@.type=="Ready")].status, NODEPOOL:metadata.labels.cloud\.google\.com/gke-nodepool' | grep -w True | awk {'print $3'} | sort | uniq -c`, hiding output unless there is an error.
549
+ [XPK] Task: `Kueue: ClusterQueue Details` is implemented by `kubectl describe ClusterQueue cluster-queue`, hiding output unless there is an error.
550
+ [XPK] Task: `Kueue: LocalQueue Details` is implemented by `kubectl describe LocalQueue multislice-queue`, hiding output unless there is an error.
551
+ [XPK] Task: `Kueue: Kueue Deployment Details` is implemented by `kubectl describe Deployment kueue-controller-manager -n kueue-system`, hiding output unless there is an error.
552
+ [XPK] Task: `Jobset: Deployment Details` is implemented by `kubectl describe Deployment jobset-controller-manager -n jobset-system`, hiding output unless there is an error.
553
+ [XPK] Task: `Kueue Manager Logs` is implemented by `kubectl logs deployment/kueue-controller-manager -n kueue-system --tail=100 --prefix=True`, hiding output unless there is an error.
554
+ [XPK] Task: `Jobset Manager Logs` is implemented by `kubectl logs deployment/jobset-controller-manager -n jobset-system --tail=100 --prefix=True`, hiding output unless there is an error.
555
+ [XPK] Task: `List Jobs with filter-by-status=EVERYTHING with filter-by-jobs=None` is implemented by `kubectl get workloads -o=custom-columns="Jobset Name:.metadata.ownerReferences[0].name,Created Time:.metadata.creationTimestamp,Priority:.spec.priorityClassName,TPU VMs Needed:.spec.podSets[0].count,TPU VMs Running/Ran:.status.admission.podSetAssignments[-1].count,TPU VMs Done:.status.reclaimablePods[0].count,Status:.status.conditions[-1].type,Status Message:.status.conditions[-1].message,Status Time:.status.conditions[-1].lastTransitionTime" `, hiding output unless there is an error.
556
+ [XPK] Task: `List Jobs with filter-by-status=QUEUED with filter-by-jobs=None` is implemented by `kubectl get workloads -o=custom-columns="Jobset Name:.metadata.ownerReferences[0].name,Created Time:.metadata.creationTimestamp,Priority:.spec.priorityClassName,TPU VMs Needed:.spec.podSets[0].count,TPU VMs Running/Ran:.status.admission.podSetAssignments[-1].count,TPU VMs Done:.status.reclaimablePods[0].count,Status:.status.conditions[-1].type,Status Message:.status.conditions[-1].message,Status Time:.status.conditions[-1].lastTransitionTime" | awk -e 'NR == 1 || ($7 ~ "Admitted|Evicted|QuotaReserved" && ($5 ~ "<none>" || $5 == 0)) {print $0}' `, hiding output unless there is an error.
557
+ [XPK] Task: `List Jobs with filter-by-status=RUNNING with filter-by-jobs=None` is implemented by `kubectl get workloads -o=custom-columns="Jobset Name:.metadata.ownerReferences[0].name,Created Time:.metadata.creationTimestamp,Priority:.spec.priorityClassName,TPU VMs Needed:.spec.podSets[0].count,TPU VMs Running/Ran:.status.admission.podSetAssignments[-1].count,TPU VMs Done:.status.reclaimablePods[0].count,Status:.status.conditions[-1].type,Status Message:.status.conditions[-1].message,Status Time:.status.conditions[-1].lastTransitionTime" | awk -e 'NR == 1 || ($7 ~ "Admitted|Evicted" && $5 ~ /^[0-9]+$/ && $5 > 0) {print $0}' `, hiding output unless there is an error.
558
+ [XPK] Find xpk inspector output file: /tmp/tmp0pd6_k1o
559
+ [XPK] Exiting XPK cleanly
560
+ ```
561
+
562
+ ## GPU usage
563
+
564
+ In order to use XPK for GPU, you can do so by using `device-type` flag.
565
+
566
+ * Cluster Create (provision reserved capacity):
567
+
568
+ ```shell
569
+ # Find your reservations
570
+ gcloud compute reservations list --project=$PROJECT_ID
571
+
572
+ # Run cluster create with reservation.
573
+ python3 xpk.py cluster create \
574
+ --cluster xpk-test --device-type=h100-80gb-8 \
575
+ --num-nodes=2 \
576
+ --reservation=$RESERVATION_ID
577
+ ```
578
+
579
+ * Cluster Delete (deprovision capacity):
580
+
581
+ ```shell
582
+ python3 xpk.py cluster delete \
583
+ --cluster xpk-test
584
+ ```
585
+
586
+ * Cluster List (see provisioned capacity):
587
+
588
+ ```shell
589
+ python3 xpk.py cluster list
590
+ ```
591
+
592
+ * Cluster Describe (see capacity):
593
+
594
+ ```shell
595
+ python3 xpk.py cluster describe \
596
+ --cluster xpk-test
597
+ ```
598
+
599
+
600
+ * Cluster Cacheimage (enables faster start times):
601
+
602
+ ```shell
603
+ python3 xpk.py cluster cacheimage \
604
+ --cluster xpk-test --docker-image gcr.io/your_docker_image \
605
+ --device-type=h100-80gb-8
606
+ ```
607
+
608
+
609
+ * [Install NVIDIA GPU device drivers](https://cloud.google.com/container-optimized-os/docs/how-to/run-gpus#install)
610
+ ```shell
611
+ # List available driver versions
612
+ gcloud compute ssh $NODE_NAME --command "sudo cos-extensions list"
613
+
614
+ # Install the default driver
615
+ gcloud compute ssh $NODE_NAME --command "sudo cos-extensions install gpu"
616
+ # OR install a specific version of the driver
617
+ gcloud compute ssh $NODE_NAME --command "sudo cos-extensions install gpu -- -version=DRIVER_VERSION"
618
+ ```
619
+
620
+ * Run a workload:
621
+
622
+ ```shell
623
+ # Submit a workload
624
+ python3 xpk.py workload create \
625
+ --cluster xpk-test --device-type h100-80gb-8 \
626
+ --workload xpk-test-workload \
627
+ --command="echo hello world"
628
+ ```
629
+
630
+ * Workload Delete (delete training job):
631
+
632
+ ```shell
633
+ python3 xpk.py workload delete \
634
+ --workload xpk-test-workload --cluster xpk-test
635
+ ```
636
+
637
+ This will only delete `xpk-test-workload` workload in `xpk-test` cluster.
638
+
639
+ * Workload Delete (delete all training jobs in the cluster):
640
+
641
+ ```shell
642
+ python3 xpk.py workload delete \
643
+ --cluster xpk-test
644
+ ```
645
+
646
+ This will delete all the workloads in `xpk-test` cluster. Deletion will only begin if you type `y` or `yes` at the prompt.
647
+
648
+ * Workload Delete supports filtering. Delete a portion of jobs that match user criteria.
649
+ * Filter by Job: `filter-by-job`
650
+
651
+ ```shell
652
+ python3 xpk.py workload delete \
653
+ --cluster xpk-test --filter-by-job=$USER
654
+ ```
655
+
656
+ This will delete all the workloads in `xpk-test` cluster whose names start with `$USER`. Deletion will only begin if you type `y` or `yes` at the prompt.
657
+
658
+ * Filter by Status: `filter-by-status`
659
+
660
+ ```shell
661
+ python3 xpk.py workload delete \
662
+ --cluster xpk-test --filter-by-status=QUEUED
663
+ ```
664
+
665
+ This will delete all the workloads in `xpk-test` cluster that have the status as Admitted or Evicted, and the number of running VMs is 0. Deletion will only begin if you type `y` or `yes` at the prompt. Status can be: `EVERYTHING`,`FINISHED`, `RUNNING`, `QUEUED`, `FAILED`, `SUCCESSFUL`.
666
+
667
+ ## CPU usage
668
+
669
+ In order to use XPK for CPU, you can do so by using `device-type` flag.
670
+
671
+ * Cluster Create (provision on-demand capacity):
672
+
673
+ ```shell
674
+ # Run cluster create with on demand capacity.
675
+ python3 xpk.py cluster create \
676
+ --cluster xpk-test \
677
+ --device-type=n2-standard-32-256 \
678
+ --num-slices=1 \
679
+ --default-pool-cpu-machine-type=n2-standard-32 \
680
+ --on-demand
681
+ ```
682
+ Note that `device-type` for CPUs is of the format <cpu-machine-type>-<number of VMs>, thus in the above example, user requests for 256 VMs of type n2-standard-32.
683
+ Currently workloads using < 1000 VMs are supported.
684
+
685
+ * Run a workload:
686
+
687
+ ```shell
688
+ # Submit a workload
689
+ python3 xpk.py workload create \
690
+ --cluster xpk-test \
691
+ --num-slices=1 \
692
+ --device-type=n2-standard-32-256 \
693
+ --workload xpk-test-workload \
694
+ --command="echo hello world"
695
+ ```
696
+
697
+ # Autoprovisioning with XPK
698
+ XPK can dynamically allocate cluster capacity using [Node Auto Provisioning, (NAP)](https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-provisioning#use_accelerators_for_new_auto-provisioned_node_pools) support.
699
+
700
+ Allow several topology sizes to be supported from one XPK cluster, and be dynamically provisioned based on incoming workload requests. XPK users will not need to re-provision the cluster manually.
701
+
702
+ Enabling autoprovisioning will take the cluster around initially up to **30 minutes to upgrade**.
703
+
704
+ ## Create a cluster with autoprovisioning:
705
+
706
+ Autoprovisioning will be enabled on the below cluster with [0, 8] chips of v4 TPU (up to 1xv4-16) to scale
707
+ between.
708
+
709
+ XPK doesn't currently support different generations of accelerators in the same cluster (like v4 and v5p TPUs).
710
+
711
+ ```shell
712
+ CLUSTER_NAME=my_cluster
713
+ NUM_SLICES=2
714
+ DEVICE_TYPE=v4-8
715
+ RESERVATION=reservation_id
716
+ PROJECT=my_project
717
+ ZONE=us-east5-b
718
+
719
+ python3 xpk.py cluster create \
720
+ --cluster $CLUSTER_NAME \
721
+ --num-slices=$NUM_SLICES \
722
+ --device-type=$DEVICE_TYPE \
723
+ --zone=$ZONE \
724
+ --project=$PROJECT \
725
+ --reservation=$RESERVATION \
726
+ --enable-autoprovisioning
727
+ ```
728
+
729
+ 1. Define the starting accelerator configuration and capacity type.
730
+
731
+ ```shell
732
+ --device-type=$DEVICE_TYPE \
733
+ --num-slice=$NUM_SLICES
734
+ ```
735
+ 2. Optionally set custom `minimum` / `maximum` chips. NAP will rescale the cluster with `maximum` - `minimum` chips. By default, `maximum` is set to the current cluster configuration size, and `minimum` is set to 0. This allows NAP to rescale with all the resources.
736
+
737
+ ```shell
738
+ --autoprovisioning-min-chips=$MIN_CHIPS \
739
+ --autoprovisioning-max-chips=$MAX_CHIPS
740
+ ```
741
+
742
+ 3. `FEATURE TO COME SOON:` Set the timeout period for when node pools will automatically be deleted
743
+ if no incoming workloads are run. This is 10 minutes currently.
744
+
745
+ 4. `FEATURE TO COME:` Set the timeout period to infinity. This will keep the idle node pool configuration always running until updated by new workloads.
746
+
747
+ ### Update a cluster with autoprovisioning:
748
+ ```shell
749
+ CLUSTER_NAME=my_cluster
750
+ NUM_SLICES=2
751
+ DEVICE_TYPE=v4-8
752
+ RESERVATION=reservation_id
753
+ PROJECT=my_project
754
+ ZONE=us-east5-b
755
+
756
+ python3 xpk.py cluster create \
757
+ --cluster $CLUSTER_NAME \
758
+ --num-slices=$NUM_SLICES \
759
+ --device-type=$DEVICE_TYPE \
760
+ --zone=$ZONE \
761
+ --project=$PROJECT \
762
+ --reservation=$RESERVATION \
763
+ --enable-autoprovisioning
764
+ ```
765
+
766
+ ### Update a previously autoprovisioned cluster with different amount of chips:
767
+
768
+ * Option 1: By creating a new cluster nodepool configuration.
769
+
770
+ ```shell
771
+ CLUSTER_NAME=my_cluster
772
+ NUM_SLICES=2
773
+ DEVICE_TYPE=v4-16
774
+ RESERVATION=reservation_id
775
+ PROJECT=my_project
776
+ ZONE=us-east5-b
777
+
778
+ # This will create 2x v4-16 node pools and set the max autoprovisioned chips to 16.
779
+ python3 xpk.py cluster create \
780
+ --cluster $CLUSTER_NAME \
781
+ --num-slices=$NUM_SLICES \
782
+ --device-type=$DEVICE_TYPE \
783
+ --zone=$ZONE \
784
+ --project=$PROJECT \
785
+ --reservation=$RESERVATION \
786
+ --enable-autoprovisioning
787
+ ```
788
+
789
+ * Option 2: By increasing the `--autoprovisioning-max-chips`.
790
+ ```shell
791
+ CLUSTER_NAME=my_cluster
792
+ NUM_SLICES=0
793
+ DEVICE_TYPE=v4-16
794
+ RESERVATION=reservation_id
795
+ PROJECT=my_project
796
+ ZONE=us-east5-b
797
+
798
+ # This will clear the node pools if they exist in the cluster and set the max autoprovisioned chips to 16
799
+ python3 xpk.py cluster create \
800
+ --cluster $CLUSTER_NAME \
801
+ --num-slices=$NUM_SLICES \
802
+ --device-type=$DEVICE_TYPE \
803
+ --zone=$ZONE \
804
+ --project=$PROJECT \
805
+ --reservation=$RESERVATION \
806
+ --enable-autoprovisioning \
807
+ --autoprovisioning-max-chips 16
808
+ ```
809
+
810
+ ## Run workloads on the cluster with autoprovisioning:
811
+ Reconfigure the `--device-type` and `--num-slices`
812
+ ```shell
813
+ CLUSTER_NAME=my_cluster
814
+ NUM_SLICES=2
815
+ DEVICE_TYPE=v4-8
816
+ NEW_RESERVATION=new_reservation_id
817
+ PROJECT=my_project
818
+ ZONE=us-east5-b
819
+ # Create a 2x v4-8 TPU workload.
820
+ python3 xpk.py workload create \
821
+ --cluster $CLUSTER \
822
+ --workload ${USER}-nap-${NUM_SLICES}x${DEVICE_TYPE}_$(date +%H-%M-%S) \
823
+ --command "echo hello world from $NUM_SLICES $DEVICE_TYPE" \
824
+ --device-type=$DEVICE_TYPE \
825
+ --num-slices=$NUM_SLICES \
826
+ --zone=$ZONE \
827
+ --project=$PROJECT
828
+
829
+ NUM_SLICES=1
830
+ DEVICE_TYPE=v4-16
831
+
832
+ # Create a 1x v4-16 TPU workload.
833
+ python3 xpk.py workload create \
834
+ --cluster $CLUSTER \
835
+ --workload ${USER}-nap-${NUM_SLICES}x${DEVICE_TYPE}_$(date +%H-%M-%S) \
836
+ --command "echo hello world from $NUM_SLICES $DEVICE_TYPE" \
837
+ --device-type=$DEVICE_TYPE \
838
+ --num-slices=$NUM_SLICES \
839
+ --zone=$ZONE \
840
+ --project=$PROJECT
841
+
842
+ # Use a different reservation from what the cluster was created with.
843
+ python3 xpk.py workload create \
844
+ --cluster $CLUSTER \
845
+ --workload ${USER}-nap-${NUM_SLICES}x${DEVICE_TYPE}_$(date +%H-%M-%S) \
846
+ --command "echo hello world from $NUM_SLICES $DEVICE_TYPE" \
847
+ --device-type=$DEVICE_TYPE \
848
+ --num-slices=$NUM_SLICES \
849
+ --zone=$ZONE \
850
+ --project=$PROJECT \
851
+ --reservation=$NEW_RESERVATION
852
+ ```
853
+
854
+ 1. (Optional) Define the capacity type. By default, the capacity type will
855
+ match with what the cluster was created with.
856
+
857
+ ```shell
858
+ --reservation=my-reservation-id | --on-demand | --spot
859
+ ```
860
+
861
+ 2. Set the topology of your workload using --device-type.
862
+
863
+ ```shell
864
+ NUM_SLICES=1
865
+ DEVICE_TYPE=v4-8
866
+ --device-type=$DEVICE_TYPE \
867
+ --num-slices=$NUM_SLICES \
868
+ ```
869
+
870
+
871
+ # How to add docker images to a xpk workload
872
+
873
+ The default behavior is `xpk workload create` will layer the local directory (`--script-dir`) into
874
+ the base docker image (`--base-docker-image`) and run the workload command.
875
+ If you don't want this layering behavior, you can directly use `--docker-image`. Do not mix arguments from the two flows in the same command.
876
+
877
+ ## Recommended / Default Docker Flow: `--base-docker-image` and `--script-dir`
878
+ This flow pulls the `--script-dir` into the `--base-docker-image` and runs the new docker image.
879
+
880
+ * The below arguments are optional by default. xpk will pull the local
881
+ directory with a generic base docker image.
882
+
883
+ - `--base-docker-image` sets the base image that xpk will start with.
884
+
885
+ - `--script-dir` sets which directory to pull into the image. This defaults to the current working directory.
886
+
887
+ See `python3 xpk.py workload create --help` for more info.
888
+
889
+ * Example with defaults which pulls the local directory into the base image:
890
+ ```shell
891
+ echo -e '#!/bin/bash \n echo "Hello world from a test script!"' > test.sh
892
+ python3 xpk.py workload create --cluster xpk-test \
893
+ --workload xpk-test-workload-base-image --command "bash test.sh" \
894
+ --tpu-type=v5litepod-16 --num-slices=1
895
+ ```
896
+
897
+ * Recommended Flow For Normal Sized Jobs (fewer than 10k accelerators):
898
+ ```shell
899
+ python3 xpk.py workload create --cluster xpk-test \
900
+ --workload xpk-test-workload-base-image --command "bash custom_script.sh" \
901
+ --base-docker-image=gcr.io/your_dependencies_docker_image \
902
+ --tpu-type=v5litepod-16 --num-slices=1
903
+ ```
904
+
905
+ ## Optional Direct Docker Image Configuration: `--docker-image`
906
+ If a user wants to directly set the docker image used and not layer in the
907
+ current working directory, set `--docker-image` to the image to be use in the
908
+ workload.
909
+
910
+ * Running with `--docker-image`:
911
+ ```shell
912
+ python3 xpk.py workload create --cluster xpk-test \
913
+ --workload xpk-test-workload-base-image --command "bash test.sh" \
914
+ --tpu-type=v5litepod-16 --num-slices=1 --docker-image=gcr.io/your_docker_image
915
+ ```
916
+
917
+ * Recommended Flow For Large Sized Jobs (more than 10k accelerators):
918
+ ```shell
919
+ python3 xpk.py cluster cacheimage \
920
+ --cluster xpk-test --docker-image gcr.io/your_docker_image
921
+ # Run workload create with the same image.
922
+ python3 xpk.py workload create --cluster xpk-test \
923
+ --workload xpk-test-workload-base-image --command "bash test.sh" \
924
+ --tpu-type=v5litepod-16 --num-slices=1 --docker-image=gcr.io/your_docker_image
925
+ ```
926
+
927
+ # More advanced facts:
928
+
929
+ * Workload create has two mutually exclusive ways to override the environment of a workload:
930
+ * a `--env` flag to specify each environment variable separately. The format is:
931
+
932
+ `--env VARIABLE1=value --env VARIABLE2=value`
933
+
934
+ * a `--env-file` flag to allow specifying the container's
935
+ environment from a file. Usage is the same as Docker's
936
+ [--env-file flag](https://docs.docker.com/engine/reference/commandline/run/#env)
937
+
938
+ Example Env File:
939
+ ```shell
940
+ LIBTPU_INIT_ARGS=--my-flag=true --performance=high
941
+ MY_ENV_VAR=hello
942
+ ```
943
+
944
+ * Workload create accepts a --debug-dump-gcs flag which is a path to GCS bucket.
945
+ Passing this flag sets the XLA_FLAGS='--xla_dump_to=/tmp/xla_dump/' and uploads
946
+ hlo dumps to the specified GCS bucket for each worker.
947
+
948
+ # Integration Test Workflows
949
+ The repository code is tested through Github Workflows and Actions. Currently three kinds of tests are performed:
950
+ * A nightly build that runs every 24 hours
951
+ * A build that runs on push to `main` branch
952
+ * A build that runs for every PR approval
953
+
954
+ More information is documented [here](https://github.com/google/xpk/tree/main/.github/workflows)
955
+
956
+ # Troubleshooting
957
+
958
+ ## `Invalid machine type` for CPUs.
959
+ XPK will create a regional GKE cluster. If you see issues like
960
+
961
+ ```shell
962
+ Invalid machine type e2-standard-32 in zone $ZONE_NAME
963
+ ```
964
+
965
+ Please select a CPU type that exists in all zones in the region.
966
+
967
+ ```shell
968
+ # Find CPU Types supported in zones.
969
+ gcloud compute machine-types list --zones=$ZONE_LIST
970
+ # Adjust default cpu machine type.
971
+ python3 xpk.py cluster create --default-pool-cpu-machine-type=CPU_TYPE ...
972
+ ```
973
+
974
+ ## Permission Issues: `requires one of ["permission_name"] permission(s)`.
975
+
976
+ 1) Determine the role needed based on the permission error:
977
+
978
+ ```shell
979
+ # For example: `requires one of ["container.*"] permission(s)`
980
+ # Add [Kubernetes Engine Admin](https://cloud.google.com/iam/docs/understanding-roles#kubernetes-engine-roles) to your user.
981
+ ```
982
+
983
+ 2) Add the role to the user in your project.
984
+
985
+ Go to [iam-admin](https://console.cloud.google.com/iam-admin/) or use gcloud cli:
986
+ ```shell
987
+ PROJECT_ID=my-project-id
988
+ CURRENT_GKE_USER=$(gcloud config get account)
989
+ ROLE=roles/container.admin # container.admin is the role needed for Kubernetes Engine Admin
990
+ gcloud projects add-iam-policy-binding $PROJECT_ID --member user:$CURRENT_GKE_USER --role=$ROLE
991
+ ```
992
+
993
+ 3) Check the permissions are correct for the users.
994
+
995
+ Go to [iam-admin](https://console.cloud.google.com/iam-admin/) or use gcloud cli:
996
+
997
+ ```shell
998
+ PROJECT_ID=my-project-id
999
+ CURRENT_GKE_USER=$(gcloud config get account)
1000
+ gcloud projects get-iam-policy $PROJECT_ID --filter="bindings.members:$CURRENT_GKE_USER" --flatten="bindings[].members"
1001
+ ```
1002
+
1003
+ 4) Confirm you have logged in locally with the correct user.
1004
+
1005
+ ```shell
1006
+ gcloud auth login
1007
+ ```
1008
+
1009
+ ### Roles needed based on permission errors:
1010
+
1011
+ * `requires one of ["container.*"] permission(s)`
1012
+
1013
+ Add [Kubernetes Engine Admin](https://cloud.google.com/iam/docs/understanding-roles#kubernetes-engine-roles) to your user.
1014
+
1015
+ * `ERROR: (gcloud.monitoring.dashboards.list) User does not have permission to access projects instance (or it may not exist)`
1016
+
1017
+ Add [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) to your user.
1018
+
1019
+
1020
+ ## Reservation Troubleshooting:
1021
+
1022
+ ### How to determine your reservation and its size / utilization:
1023
+
1024
+ ```shell
1025
+ PROJECT_ID=my-project
1026
+ ZONE=us-east5-b
1027
+ RESERVATION=my-reservation-name
1028
+ # Find the reservations in your project
1029
+ gcloud beta compute reservations list --project=$PROJECT_ID
1030
+ # Find the tpu machine type and current utilization of a reservation.
1031
+ gcloud beta compute reservations describe $RESERVATION --project=$PROJECT_ID --zone=$ZONE
1032
+ ```
1033
+
1034
+ # TPU Workload Debugging
1035
+
1036
+ ## Verbose Logging
1037
+ If you are having trouble with your workload, try setting the `--enable-debug-logs` when you schedule it. This will give you more detailed logs to help pinpoint the issue. For example:
1038
+ ```shell
1039
+ python3 xpk.py workload create \
1040
+ --cluster --workload xpk-test-workload \
1041
+ --command="echo hello world" --enable-debug-logs
1042
+ ```
1043
+ Please check [libtpu logging](https://cloud.google.com/tpu/docs/troubleshooting/trouble-tf#debug_logs) and [Tensorflow logging](https://deepreg.readthedocs.io/en/latest/docs/logging.html#tensorflow-logging) for more information about the flags that are enabled to get the logs.
1044
+
1045
+ ## Collect Stack Traces
1046
+ [cloud-tpu-diagnostics](https://pypi.org/project/cloud-tpu-diagnostics/) PyPI package can be used to generate stack traces for workloads running in GKE. This package dumps the Python traces when a fault such as segmentation fault, floating-point exception, or illegal operation exception occurs in the program. Additionally, it will also periodically collect stack traces to help you debug situations when the program is unresponsive. You must make the following changes in the docker image running in a Kubernetes main container to enable periodic stack trace collection.
1047
+ ```shell
1048
+ # main.py
1049
+
1050
+ from cloud_tpu_diagnostics import diagnostic
1051
+ from cloud_tpu_diagnostics.configuration import debug_configuration
1052
+ from cloud_tpu_diagnostics.configuration import diagnostic_configuration
1053
+ from cloud_tpu_diagnostics.configuration import stack_trace_configuration
1054
+
1055
+ stack_trace_config = stack_trace_configuration.StackTraceConfig(
1056
+ collect_stack_trace = True,
1057
+ stack_trace_to_cloud = True)
1058
+ debug_config = debug_configuration.DebugConfig(
1059
+ stack_trace_config = stack_trace_config)
1060
+ diagnostic_config = diagnostic_configuration.DiagnosticConfig(
1061
+ debug_config = debug_config)
1062
+
1063
+ with diagnostic.diagnose(diagnostic_config):
1064
+ main_method() # this is the main method to run
1065
+ ```
1066
+ This configuration will start collecting stack traces inside the `/tmp/debugging` directory on each Kubernetes Pod.
1067
+
1068
+ ### Explore Stack Traces
1069
+ To explore the stack traces collected in a temporary directory in Kubernetes Pod, you can run the following command to configure a sidecar container that will read the traces from `/tmp/debugging` directory.
1070
+ ```shell
1071
+ python3 xpk.py workload create \
1072
+ --workload xpk-test-workload --command "python3 main.py" --cluster \
1073
+ xpk-test --tpu-type=v5litepod-16 --deploy-stacktrace-sidecar
1074
+ ```