[PUBLISH] Nomad Docs: Publish nomad/1.11.1 release docs (#1488)

🚧 `hashicorp/web-unified-docs` publication PR

**Triggered by**: @aimeeu with a Github action
**Release branch**: `nomad/1.11.1`
**Merge target**:   `main`

Author: aimeeu

content/nomad/v1.10.x/content/docs/job-declare/task-driver/docker.mdx

@@ -608,8 +608,6 @@ The `auth` object supports the following keys:
 
 - `password` - (Optional) The account password.
 
-- `email` - (Optional) The account email.
-
 - `server_address` - (Optional) The server domain/IP without the protocol.
   Docker Hub is used by default.
 

content/nomad/v1.10.x/content/docs/other-specifications/volume/host.mdx

@@ -125,6 +125,10 @@ user running the Nomad client agent, which is commonly `0` (root).
 
 The user and group IDs must be present on any node that may receive the volume.
 
+On Windows, the `uid` and `gid` values are ignored. In addition, only the 0o200
+bit (owner writable) mode is used; it controls whether the file's read-only
+attribute is set or cleared.
+
 ### mkdir example
 
 <CodeBlockConfig filename="mkdir.volume.hcl">

content/nomad/v1.11.x/content/docs/configuration/client.mdx

@@ -93,11 +93,13 @@ client {
 - `disk_total_mb` `(int:0)` - Specifies an override for the total disk space
   fingerprint attribute. This value is not used by the scheduler unless you have
   constraints set on the attribute `unique.storage.bytestotal`. The actual total
-  disk space can be determined via the [Read Stats API](/nomad/api-docs/client#read-stats)
-
-- `disk_free_mb` `(int:0)` - Specifies the disk space free for scheduling
-  allocations. If set, this value overrides any detected free disk space. This
-  value can be seen in `nomad node status` under Allocated Resources.
+  disk space can be determined via the [Read Stats
+  API](/nomad/api-docs/client#read-stats)
+  
+- `disk_free_mb` `(int:0)` - Previously specified the disk space free for
+  scheduling allocations. If set, it would override any detected free disk
+  space. This value has been deprecated and is now ignored by Nomad clients. Use
+  [`client.reserved.disk`](#reserved-parameters) instead.
 
 - `min_dynamic_port` `(int:20000)` - Specifies the minimum dynamic port to be
   assigned. Individual ports and ranges of ports may be excluded from dynamic

content/nomad/v1.11.x/content/docs/deploy/task-driver/qemu.mdx

@@ -43,22 +43,37 @@ way to retrieve the image being run.
 The `qemu` driver will set the following client attributes:
 
 - `driver.qemu` - Set to `1` if QEMU is found on the host node. Nomad determines
-  this by executing `qemu-system-x86_64 -version` on the host and parsing the output
-- `driver.qemu.version` - Version of `qemu-system-x86_64`, ex: `2.4.0`
+  this by executing the first found QEMU binary with `--version` on the client
+  and parsing the output. Nomad does not get the version of each individual QEMU
+  emulator.
+- `driver.qemu.version` - Version found running the command for `driver.qemu`;
+  for example: `2.4.0`
+- `driver.qemu.emulators` - A comma separated list of emulators detected on the client.
 
 Here is an example of using these properties in a job file:
 
 ```hcl
 job "docs" {
   # Only run this job where the qemu version is higher than 1.2.3.
   constraint {
-    attribute = "${driver.qemu.version}"
+    attribute = "${attr.driver.qemu.version}"
     operator  = ">"
     value     = "1.2.3"
   }
 }
 ```
 
+```hcl
+job "docs" {
+  # Only run this job where the the qemu-system-aarch64 emulator was detected.
+  constraint {
+    attribute = "${attr.driver.qemu.emulators}"
+    operator  = "set_contains"
+    value     = "aarch64"
+  }
+}
+```
+
 ## Plugin Options
 
 ```hcl
@@ -78,6 +93,10 @@ plugin "qemu" {
   including flags that provide the VM with access to host devices such
   as USB drives. Refer to the [QEMU documentation] for the available
   flags.
+- `emulators_allowlist` (`[]string`: `[]`) - Specifies the allowed emulators
+  tasks may use. When specified, Nomad only fingerprints this list and does not
+  allow tasks to run using other emulators. Defaults to fingerprinting and
+  allowing all emulators.
 
 ## Resource Isolation
 

content/nomad/v1.11.x/content/docs/job-declare/task-driver/docker.mdx

@@ -608,8 +608,6 @@ The `auth` object supports the following keys:
 
 - `password` - (Optional) The account password.
 
-- `email` - (Optional) The account email.
-
 - `server_address` - (Optional) The server domain/IP without the protocol.
   Docker Hub is used by default.
 

content/nomad/v1.11.x/content/docs/job-declare/task-driver/qemu.mdx

@@ -14,8 +14,9 @@ great performance. Currently the `qemu` driver can map a set of ports from the
 host machine to the guest virtual machine, and provides configuration for
 resource allocation.
 
-The `qemu` driver can execute any regular `qemu` image (e.g. `qcow`, `img`,
-`iso`), and is currently invoked with `qemu-system-x86_64`.
+The `qemu` driver can execute any regular `qemu` image, such as `qcow`, `img`,
+and `iso`. Nomad uses the QEMU binary specified by the `emulator` parameter. For
+example, if you specify `x86_64d, Nomad uses `qemu-system-x86_64`.
 
 The driver requires the image to be accessible from the Nomad client via the
 [`artifact` downloader](/nomad/docs/job-specification/artifact).
@@ -31,6 +32,8 @@ task "webservice" {
 
   config {
     image_path        = "/path/to/my/linux.img"
+    emulator          = "x86_64"
+    machine_type      = "q35"
     accelerator       = "kvm"
     graceful_shutdown = true
     args              = ["-nodefaults", "-nodefconfig"]
@@ -40,10 +43,15 @@ task "webservice" {
 
 The `qemu` driver supports the following configuration in the job spec:
 
-- `image_path` - The path to the downloaded image. In most cases this will just
-  be the name of the image. However, if the supplied artifact is an archive that
-  contains the image in a subfolder, the path will need to be the relative path
-  (`subdir/from_archive/my.img`).
+- `image_path` - The path to the downloaded image. In most cases this is the
+  name of the image. However, if the supplied artifact is an archive that
+  contains the image in a subfolder, the path needs to be the relative path
+  (`subdir/from_archive/my.img`). Nomad gives this image an ID of "image0".
+
+- `emulator` `(string: "x86_64")` - The architecture of the QEMU emulator used to
+  run the virtual machine.
+
+- `machine_type` `(string: "pc")` - Used to select the emulated machine by name.
 
 - `drive_interface` - (Optional) This option defines on which type of interface
   the drive is connected. Available types are: `ide`, `scsi`, `sd`, `mtd`,

content/nomad/v1.11.x/content/docs/job-specification/identity.mdx

@@ -12,6 +12,7 @@ description: |-
     ['job', 'group', 'service', 'identity'],
     ['job', 'group', 'task', 'identity'],
     ['job', 'group', 'task', 'service', 'identity'],
+    ['job', 'group', 'service', 'connect', 'sidecar_task', 'identity'],
   ]}
 />
 

content/nomad/v1.11.x/content/docs/job-specification/secret.mdx

@@ -89,9 +89,9 @@ Nomad extends the provider list via the use of custom providers plugins. Custom
 providers must implement both the `fingerprint` and `fetch` functionality. You
 must place custom providers in the `common_plugin_dir/secrets/` subdirectory. On
 startup, the Nomad client fingerprints executables in the secrets directory by
-executing it with the first argument of `fingerblock`. When using a custom
-plugin "foo", Nomad looks for an executable "foo" and runs it with the first
-argument being "fetch", and the second argument being the secret's path
+executing it with the first argument being `fingerprint`. When a task using a custom
+plugin "foo" to fetch a secret, Nomad looks for an executable "foo" and runs it with
+the first argument being "fetch", and the second argument being the secret's path
 parameter. Refer to the [plugin authoring][secret-provider] guide on secret providers
 for an example custom provider.
 

content/nomad/v1.11.x/content/docs/job-specification/sidecar_task.mdx

@@ -156,6 +156,11 @@ meta.connect.sidecar_image = custom/envoy-${NOMAD_envoy_version}:latest
 - `volume_mount` <code>([VolumeMount][]: nil)</code> - Specifies where a group
   volume should be mounted.
 
+- `identity` <code>([Identity][]: nil)</code> - Expose an extra [Workload Identity][]
+  to the task. Nomad automatically configures Consul Service Mesh sidecars with
+  the required identities to communicate with Consul. Specifying this block lets
+  you add extra identities that can be consumed by third-party services.
+
 ## Examples
 
 The following example configures resources for the sidecar task and other configuration.
@@ -181,6 +186,8 @@ The following example configures resources for the sidecar task and other config
 [group]: /nomad/docs/job-specification/group 'Nomad group Job Specification'
 [interpolation]: /nomad/docs/reference/runtime-variable-interpolation 'Nomad interpolation'
 [job]: /nomad/docs/job-specification/job 'Nomad job Job Specification'
+[Identity]: /nomad/docs/job-specification/identity 'Nomad identity Job Specification'
+[Workload Identity]: /nomad/docs/concepts/workload-identity
 [logs]: /nomad/docs/job-specification/logs 'Nomad logs Job Specification'
 [resources]: /nomad/docs/job-specification/resources 'Nomad resources Job Specification'
 [sidecar_service]: /nomad/docs/job-specification/sidecar_service 'Nomad sidecar service Specification'

content/nomad/v1.11.x/content/docs/other-specifications/acl-policy.mdx

@@ -117,6 +117,7 @@ The `policy` field for namespace rules can have one of the following values:
 - `write`: allow the resource to be read and modified
 - `deny`: do not allow the resource to be read or modified. Deny takes
   precedence when multiple policies are associated with a token.
+- `scale`: allow the resource to be scaled by the nomad-autoscaler
 
 In addition to the coarse-grained `policy`, you can provide a fine-grained list
 of `capabilities`. This includes:
@@ -171,7 +172,7 @@ The coarse-grained policy permissions are shorthand for these fine-grained names
 | `deny`  | deny                                                                                                                                                                                                                                                                                                      |
 | `read`  | list-jobs<br />parse-job<br />read-job<br />csi-list-volume<br />csi-read-volume<br />host-volume-read<br />list-scaling-policies<br />read-scaling-policy<br />read-job-scaling                                                                                                                                                |
 | `write` | list-jobs<br />parse-job<br />read-job<br />submit-job<br />dispatch-job<br />read-logs<br />read-fs<br />alloc-exec<br />alloc-lifecycle<br />csi-write-volume<br />csi-mount-volume<br />host-volume-write<br />list-scaling-policies<br />read-scaling-policy<br />read-job-scaling<br />scale-job<br />submit-recommendation |
-| `scale` | list-scaling-policies<br />read-scaling-policy<br />read-job-scaling<br />scale-job                                                                                                                                                                                                                       |
+| `scale` | list-scaling-policies<br />read-scaling-policy<br />read-job-scaling<br />scale-job<br />read-job<br />submit-recommendation                                                                                                                                                                                                                 |