Github user zentol commented on a diff in the pull request:
https://github.com/apache/flink/pull/5463#discussion_r167613681
--- Diff: docs/ops/config.md ---
@@ -408,38 +408,7 @@ of the JobManager, because the same ActorSystem is
used. Its not possible to use
### YARN
-- `containerized.heap-cutoff-ratio`: (Default 0.25) Percentage of heap
space to remove from containers started by YARN. When a user requests a certain
amount of memory for each TaskManager container (for example 4 GB), we can not
pass this amount as the maximum heap space for the JVM (`-Xmx` argument)
because the JVM is also allocating memory outside the heap. YARN is very strict
with killing containers which are using more memory than requested. Therefore,
we remove this fraction of the memory from the requested heap as a safety
margin and add it to the memory used off-heap.
-
-- `containerized.heap-cutoff-min`: (Default 600 MB) Minimum amount of
memory to cut off the requested heap size.
-
-- `yarn.maximum-failed-containers` (Default: number of requested
containers). Maximum number of containers the system is going to reallocate in
case of a failure.
-
-- `yarn.application-attempts` (Default: 1). Number of ApplicationMaster
restarts. Note that that the entire Flink cluster will restart and the YARN
Client will loose the connection. Also, the JobManager address will change and
you'll need to set the JM host:port manually. It is recommended to leave this
option at 1.
-
-- `yarn.heartbeat-delay` (Default: 5 seconds). Time between heartbeats
with the ResourceManager.
-
-- `yarn.properties-file.location` (Default: temp directory). When a Flink
job is submitted to YARN, the JobManager's host and the number of available
processing slots is written into a properties file, so that the Flink client is
able to pick those details up. This configuration parameter allows changing the
default location of that file (for example for environments sharing a Flink
installation between users)
-
-- `yarn.containers.vcores` The number of virtual cores (vcores) per YARN
container. By default, the number of `vcores` is set to the number of slots per
TaskManager, if set, or to 1, otherwise.
-
-- `containerized.master.env.`*ENV_VAR1=value* Configuration values
prefixed with `containerized.master.env.` will be passed as environment
variables to the ApplicationMaster/JobManager process. For example for passing
`LD_LIBRARY_PATH` as an env variable to the ApplicationMaster, set:
-
- `containerized.master.env.LD_LIBRARY_PATH: "/usr/lib/native"`
-
-- `containerized.taskmanager.env.` Similar to the configuration prefix
about, this prefix allows setting custom environment variables for the
TaskManager processes.
-
-- `yarn.container-start-command-template`: Flink uses the following
template when starting on YARN:
-`%java% %jvmmem% %jvmopts% %logging% %class% %args% %redirects%`. This
configuration parameter allows users
-to pass custom settings (such as JVM paths, arguments etc.). Note that in
most cases, it is sufficient to
-use the `env.java.opts` setting, which is the `%jvmopts%` variable in the
String.
-
-- `yarn.application-master.port` (Default: 0, which lets the OS choose an
ephemeral port) With this configuration option, users can specify a port, a
range of ports or a list of ports for the Application Master (and JobManager)
RPC port. By default we recommend using the default value (0) to let the
operating system choose an appropriate port. In particular when multiple AMs
are running on the same physical host, fixed port assignments prevent the AM
from starting.
-
- For example when running Flink on YARN on an environment with a
restrictive firewall, this option allows specifying a range of allowed ports.
-
-- `yarn.tags` A comma-separated list of tags to apply to the Flink YARN
application.
-
-- `yarn.per-job-cluster.include-user-jar` (Default: ORDER) Control whether
and how the user-jar is included in the system class path for per-job clusters.
Setting this parameter to `DISABLED` causes the jar to be included in the user
class path instead. Setting this parameter to one of `FIRST`, `LAST` or `ORDER`
causes the jar to be included in the system class path, with the jar either
being placed at the beginning of the class path (`FIRST`), at the end (`LAST`),
or based on the lexicographic order (`ORDER`).
--- End diff --
you can, I'll update the description. Another case where enum ConfigOptions
would be useful.
---
