Github user aljoscha commented on a diff in the pull request:

    https://github.com/apache/flink/pull/5463#discussion_r167608886
  
    --- 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't set `DISABLED` anymore?


---

Reply via email to