[jira] [Commented] (YARN-9044) LogsCLI should contact ATSv2 for "-am" option
[
https://issues.apache.org/jira/browse/YARN-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698514#comment-16698514
]
Suma Shivaprasad commented on YARN-9044:
[~rohithsharma] +1. One minor comment - Please move this section to a private
method to remove duplication
{ noformat}
if (YarnConfiguration.timelineServiceV1Enabled(conf)) {
690 amContainersList =
691 getAMContainerInfoForAHSWebService(conf, appId);
692 getAMContainerLists =
693
createContainerLogsRequestForMasterContainer(requests,
694 request, amContainersList, "amContainerId");
695 }
{ noformat}
> LogsCLI should contact ATSv2 for "-am" option
> -
>
> Key: YARN-9044
> URL: https://issues.apache.org/jira/browse/YARN-9044
> Project: Hadoop YARN
> Issue Type: Bug
>Reporter: Rohith Sharma K S
>Assignee: Rohith Sharma K S
>Priority: Major
> Attachments: YARN-9044.01.patch, YARN-9044.01.patch
>
>
> *yarn logs -applicationId appId -am 1* contact ATS1.5 even though it is not
> configured. Rather LogsCLI should contact ATSv2 for AM container info.
> Alternative to above one can use *yarn logs -containerId *
> to fetch logs. But -am option should also work along with ATSv2.0
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-9044) LogsCLI should contact ATSv2 for "-am" option
[ https://issues.apache.org/jira/browse/YARN-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698422#comment-16698422 ] Rohith Sharma K S commented on YARN-9044: - [~suma.shivaprasad] [~sunilg] Could you please review this patch? > LogsCLI should contact ATSv2 for "-am" option > - > > Key: YARN-9044 > URL: https://issues.apache.org/jira/browse/YARN-9044 > Project: Hadoop YARN > Issue Type: Bug >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S >Priority: Major > Attachments: YARN-9044.01.patch, YARN-9044.01.patch > > > *yarn logs -applicationId appId -am 1* contact ATS1.5 even though it is not > configured. Rather LogsCLI should contact ATSv2 for AM container info. > Alternative to above one can use *yarn logs -containerId * > to fetch logs. But -am option should also work along with ATSv2.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9050) Usability improvements for scheduler activities
[
https://issues.apache.org/jira/browse/YARN-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tao Yang updated YARN-9050:
---
Description:
We have did some usability improvements for scheduler activities based on
YARN3.1 in our cluster as follows:
1. Not available for multi-thread asynchronous scheduling. App and node
activites maybe confused when multiple scheduling threads record activites of
different allocation processes in the same variables like appsAllocation and
recordingNodesAllocation in ActivitiesManager. I think these variables should
be thread-local to make activities clear between multiple threads.
2. Incomplete activites for multi-node lookup machanism, since ActivitiesLogger
will skip recording through {{if (node == null || activitiesManager == null)
return; }} when node is null which represents this allocation is for
multi-nodes. We need support recording activities for multi-node lookup
machanism.
3. Current app activites can not meet requirements of diagnostics, for example,
we can know that node doesn't match request but hard to know why, especially
when using placement constraints, it's difficult to make a detailed diagnosis
manually. So I propose to improve the diagnoses of activites, add diagnosis for
placement constraints check, update insufficient resource diagnosis with
detailed info (like 'insufficient resource names:[memory-mb]') and so on.
4. Add more useful fields for app activities, in some scenarios we need to
distinguish different requests but can't locate requests based on app
activities info, there are some other fields can help to filter what we want
such as allocation tags. We have added containerPriority, allocationRequestId
and allocationTags fields in AppAllocation.
5. Filter app activities by key fields, sometimes the results of app activities
is massive, it's hard to find what we want. We have support filter by
allocation-tags to meet requirements from some apps, more over, we can take
container-priority and allocation-request-id as candidates if necessary.
6. Aggragate app activities by diagnoses. For a single allocation process,
activities still can be massive in a large cluster, we frequently want to know
why request can't be allocated in cluster, it's hard to check every node
manually in a large cluster, so that aggragation for app activities by
diagnoses is neccessary to solve this trouble. We have added groupingType
parameter for app-activities REST API for this, supports grouping by
diagnositics and example like this:
!image-2018-11-23-16-46-38-138.png!
I think we can have a discuss about these points, useful improvements which can
be accepted will be added into the patch. Thanks.
was:
We have did some usability improvements for scheduler activities based YARN3.1
in our cluster as follows:
1. Not available for multi-thread asynchronous scheduling. App and node
activites maybe confused when multiple scheduling threads record activites of
different allocation processes in the same variables like appsAllocation and
recordingNodesAllocation in ActivitiesManager. I think these variables should
be thread-local to make activities clear between multiple threads.
2. Incomplete activites for multi-node lookup machanism, since ActivitiesLogger
will skip recording through {{if (node == null || activitiesManager == null)
return; }} when node is null which represents this allocation is for
multi-nodes. We need support recording activities for multi-node lookup
machanism.
3. Current app activites can not meet requirements of diagnostics, for example,
we can know that node doesn't match request but hard to know why, especially
when using placement constraints, it's difficult to make a detailed diagnosis
manually. So I propose to improve the diagnoses of activites, add diagnosis for
placement constraints check, update insufficient resource diagnosis with
detailed info (like 'insufficient resource names:[memory-mb]') and so on.
4. Add more useful fields for app activities, in some scenarios we need to
distinguish different requests but can't locate requests based on app
activities info, there are some other fields can help to filter what we want
such as allocation tags. We have added containerPriority, allocationRequestId
and allocationTags fields in AppAllocation.
5. Filter app activities by key fields, sometimes the results of app activities
is massive, it's hard to find what we want. We have support filter by
allocation-tags to meet requirements from some apps, more over, we can take
container-priority and allocation-request-id as candidates if necessary.
6. Aggragate app activities by diagnoses. For a single allocation process,
activities still can be massive in a large cluster, we frequently want to know
why request can't be allocated in cluster, it's hard to check every node
manually in a large cluster, so that aggragation for app activities by
[jira] [Commented] (YARN-9051) Integrate multiple CustomResourceTypesConfigurationProvider implementations into one
[
https://issues.apache.org/jira/browse/YARN-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698411#comment-16698411
]
Hadoop QA commented on YARN-9051:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 15 new or modified test
files. {color} |
|| || || || {color:brown} trunk Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
0s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 18m
56s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 14m
35s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
58s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 3m
51s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
18m 35s{color} | {color:green} branch has no errors when building and testing
our client artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
25s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
9s{color} | {color:green} trunk passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
22s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 13m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 13m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
47s{color} | {color:green} root: The patch generated 0 new + 281 unchanged - 2
fixed = 281 total (was 283) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 3m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
10m 41s{color} | {color:green} patch has no errors when building and testing
our client artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
58s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
35s{color} | {color:green} hadoop-yarn-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 19m
8s{color} | {color:green} hadoop-yarn-server-nodemanager in the patch passed.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}104m 41s{color}
| {color:red} hadoop-yarn-server-resourcemanager in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 9m 59s{color}
| {color:red} hadoop-mapreduce-client-app in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}130m 11s{color}
| {color:red} hadoop-mapreduce-client-jobclient in the patch failed. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m
43s{color} | {color:red} The patch generated 1 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}376m 33s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.mapreduce.jobhistory.TestEvents |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f |
| JIRA Issue | YARN-9051 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12949435/YARN-9051.001.patch |
| Optional Tests |
[jira] [Commented] (YARN-9053) Support set environment variables for Docker Containers In nonEntryPoint mode
[
https://issues.apache.org/jira/browse/YARN-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698386#comment-16698386
]
Charo Zhang commented on YARN-9053:
---
[~eyang] we tested in non-entry point mode, due to be lack of
{code:java}
runCommand.addEnv(environment);
{code}
Environment variables are not written to docker container. After we added it in
non-entry point mode, all -shell_env values are added to containers. Maybe it's
really a bug, addEnv method only used in entry point mode by searching.
> Support set environment variables for Docker Containers In nonEntryPoint mode
> -
>
> Key: YARN-9053
> URL: https://issues.apache.org/jira/browse/YARN-9053
> Project: Hadoop YARN
> Issue Type: New Feature
> Components: nodemanager
>Affects Versions: 3.1.1
>Reporter: Charo Zhang
>Priority: Major
> Labels: Docker
> Attachments: YARN-9053.patch
>
>
> In yarn 3.1.1, users can only set environment variables with "-shell_env" in
> ENTRYPOINT mode, and variables must be registered in
> yarn.nodemanager.env-whitelist.
> But in nonEntryPoint mode, we should allow users to set environment variables
> like "-e KEY=VAULE" in docker run command, too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-9052) Replace all MockRM submit method definitions with a builder
[
https://issues.apache.org/jira/browse/YARN-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698342#comment-16698342
]
Hadoop QA commented on YARN-9052:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 81 new or modified test
files. {color} |
|| || || || {color:brown} trunk Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 19m
13s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 15m
52s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
3s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m
7s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
17m 1s{color} | {color:green} branch has no errors when building and testing
our client artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
1s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
39s{color} | {color:green} trunk passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 14m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 14m
23s{color} | {color:green} the patch passed {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
3m 30s{color} | {color:orange} root: The patch generated 119 new + 1864
unchanged - 39 fixed = 1983 total (was 1903) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
10m 28s{color} | {color:green} patch has no errors when building and testing
our client artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
22s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}101m 26s{color}
| {color:red} hadoop-yarn-server-resourcemanager in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 25m 35s{color}
| {color:red} hadoop-yarn-client in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 9m 58s{color}
| {color:red} hadoop-mapreduce-client-app in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
42s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}235m 29s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.yarn.server.resourcemanager.TestNodeBlacklistingOnAMFailures |
| | hadoop.yarn.client.api.impl.TestAMRMClient |
| | hadoop.mapreduce.jobhistory.TestEvents |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f |
| JIRA Issue | YARN-9052 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12949432/YARN-9052.002.patch |
| Optional Tests | dupname asflicense compile javac javadoc mvninstall
mvnsite unit shadedclient findbugs checkstyle |
| uname | Linux 6e7bcf78cbc5 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24
[jira] [Updated] (YARN-9051) Integrate multiple CustomResourceTypesConfigurationProvider implementations into one
[
https://issues.apache.org/jira/browse/YARN-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Szilard Nemeth updated YARN-9051:
-
Attachment: YARN-9051.001.patch
> Integrate multiple CustomResourceTypesConfigurationProvider implementations
> into one
>
>
> Key: YARN-9051
> URL: https://issues.apache.org/jira/browse/YARN-9051
> Project: Hadoop YARN
> Issue Type: Improvement
>Reporter: Szilard Nemeth
>Assignee: Szilard Nemeth
>Priority: Minor
> Attachments: YARN-9051.001.patch
>
>
> CustomResourceTypesConfigurationProvider (extends LocalConfigurationProvider)
> has 5 implementations on trunk nowadays.
> These could be integrated into 1 common class.
> Also,
> {{org.apache.hadoop.yarn.util.resource.TestResourceUtils#addNewTypesToResources}}
> has similar functionality so this can be considered as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9052) Replace all MockRM submit method definitions with a builder
[ https://issues.apache.org/jira/browse/YARN-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Szilard Nemeth updated YARN-9052: - Attachment: YARN-9052.002.patch > Replace all MockRM submit method definitions with a builder > --- > > Key: YARN-9052 > URL: https://issues.apache.org/jira/browse/YARN-9052 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Szilard Nemeth >Assignee: Szilard Nemeth >Priority: Minor > Attachments: YARN-9052.001.patch, YARN-9052.002.patch > > > MockRM has 31 definitions of submitApp, most of them having more than > acceptable number of parameters, ranging from 2 to even 22 parameters, which > makes the code completely unreadable. > On top of unreadability, it's very hard to follow what RmApp will be produced > for tests as they often pass a lot of empty / null values as parameters. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-9053) Support set environment variables for Docker Containers In nonEntryPoint mode
[ https://issues.apache.org/jira/browse/YARN-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698231#comment-16698231 ] Eric Yang commented on YARN-9053: - In non-entry point mode, environment is still supported via -shell_env if I am not mistaken. The -e KEY=VALUE is not necessary because environment variables are written to a launch script and run in docker container. > Support set environment variables for Docker Containers In nonEntryPoint mode > - > > Key: YARN-9053 > URL: https://issues.apache.org/jira/browse/YARN-9053 > Project: Hadoop YARN > Issue Type: New Feature > Components: nodemanager >Affects Versions: 3.1.1 >Reporter: Charo Zhang >Priority: Major > Labels: Docker > Attachments: YARN-9053.patch > > > In yarn 3.1.1, users can only set environment variables with "-shell_env" in > ENTRYPOINT mode, and variables must be registered in > yarn.nodemanager.env-whitelist. > But in nonEntryPoint mode, we should allow users to set environment variables > like "-e KEY=VAULE" in docker run command, too. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-5168) Add port mapping handling when docker container use bridge network
[
https://issues.apache.org/jira/browse/YARN-5168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698228#comment-16698228
]
Eric Yang commented on YARN-5168:
-
[~liuxun323] Thank you for the patch.
{quote}
I don't know where to display the port information in YARN UI 2.
{quote}
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-ui/src/main/webapp/app/templates/components/container-table.hbs
is the container view, and the port lists can be added to same table.
2 and 3 looks good to me.
> Add port mapping handling when docker container use bridge network
> --
>
> Key: YARN-5168
> URL: https://issues.apache.org/jira/browse/YARN-5168
> Project: Hadoop YARN
> Issue Type: Sub-task
>Reporter: Jun Gong
>Assignee: Xun Liu
>Priority: Major
> Labels: Docker
> Attachments: YARN-5168.001.patch, YARN-5168.002.patch,
> YARN-5168.003.patch, YARN-5168.004.patch, YARN-5168.005.patch,
> YARN-5168.006.patch, YARN-5168.007.patch, YARN-5168.008.patch
>
>
> YARN-4007 addresses different network setups when launching the docker
> container. We need support port mapping when docker container uses bridge
> network.
> The following problems are what we faced:
> 1. Add "-P" to map docker container's exposed ports to automatically.
> 2. Add "-p" to let user specify specific ports to map.
> 3. Add service registry support for bridge network case, then app could find
> each other. It could be done out of YARN, however it might be more convenient
> to support it natively in YARN.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-9053) Support set environment variables for Docker Containers In nonEntryPoint mode
[ https://issues.apache.org/jira/browse/YARN-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698167#comment-16698167 ] Charo Zhang commented on YARN-9053: --- [~eyang] how do you think of this issue and patch? > Support set environment variables for Docker Containers In nonEntryPoint mode > - > > Key: YARN-9053 > URL: https://issues.apache.org/jira/browse/YARN-9053 > Project: Hadoop YARN > Issue Type: New Feature > Components: nodemanager >Affects Versions: 3.1.1 >Reporter: Charo Zhang >Priority: Major > Labels: Docker > Attachments: YARN-9053.patch > > > In yarn 3.1.1, users can only set environment variables with "-shell_env" in > ENTRYPOINT mode, and variables must be registered in > yarn.nodemanager.env-whitelist. > But in nonEntryPoint mode, we should allow users to set environment variables > like "-e KEY=VAULE" in docker run command, too. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9053) Support set environment variables for Docker Containers In nonEntryPoint mode
[ https://issues.apache.org/jira/browse/YARN-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charo Zhang updated YARN-9053: -- Attachment: YARN-9053.patch > Support set environment variables for Docker Containers In nonEntryPoint mode > - > > Key: YARN-9053 > URL: https://issues.apache.org/jira/browse/YARN-9053 > Project: Hadoop YARN > Issue Type: New Feature > Components: nodemanager >Affects Versions: 3.1.1 >Reporter: Charo Zhang >Priority: Major > Labels: Docker > Attachments: YARN-9053.patch > > > In yarn 3.1.1, users can only set environment variables with "-shell_env" in > ENTRYPOINT mode, and variables must be registered in > yarn.nodemanager.env-whitelist. > But in nonEntryPoint mode, we should allow users to set environment variables > like "-e KEY=VAULE" in docker run command, too. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Created] (YARN-9053) Support set environment variables for Docker Containers In nonEntryPoint mode
Charo Zhang created YARN-9053: - Summary: Support set environment variables for Docker Containers In nonEntryPoint mode Key: YARN-9053 URL: https://issues.apache.org/jira/browse/YARN-9053 Project: Hadoop YARN Issue Type: New Feature Affects Versions: 3.1.1 Reporter: Charo Zhang In yarn 3.1.1, users can only set environment variables with "-shell_env" in ENTRYPOINT mode, and variables must be registered in yarn.nodemanager.env-whitelist. But in nonEntryPoint mode, we should allow users to set environment variables like "-e KEY=VAULE" in docker run command, too. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9053) Support set environment variables for Docker Containers In nonEntryPoint mode
[ https://issues.apache.org/jira/browse/YARN-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charo Zhang updated YARN-9053: -- Labels: Docker (was: ) > Support set environment variables for Docker Containers In nonEntryPoint mode > - > > Key: YARN-9053 > URL: https://issues.apache.org/jira/browse/YARN-9053 > Project: Hadoop YARN > Issue Type: New Feature >Affects Versions: 3.1.1 >Reporter: Charo Zhang >Priority: Major > Labels: Docker > > In yarn 3.1.1, users can only set environment variables with "-shell_env" in > ENTRYPOINT mode, and variables must be registered in > yarn.nodemanager.env-whitelist. > But in nonEntryPoint mode, we should allow users to set environment variables > like "-e KEY=VAULE" in docker run command, too. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Updated] (YARN-9053) Support set environment variables for Docker Containers In nonEntryPoint mode
[ https://issues.apache.org/jira/browse/YARN-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charo Zhang updated YARN-9053: -- Component/s: nodemanager > Support set environment variables for Docker Containers In nonEntryPoint mode > - > > Key: YARN-9053 > URL: https://issues.apache.org/jira/browse/YARN-9053 > Project: Hadoop YARN > Issue Type: New Feature > Components: nodemanager >Affects Versions: 3.1.1 >Reporter: Charo Zhang >Priority: Major > Labels: Docker > > In yarn 3.1.1, users can only set environment variables with "-shell_env" in > ENTRYPOINT mode, and variables must be registered in > yarn.nodemanager.env-whitelist. > But in nonEntryPoint mode, we should allow users to set environment variables > like "-e KEY=VAULE" in docker run command, too. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
