Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

YARN-1964 Launching containers from docker #6

Closed

Conversation

ashahab-altiscale
Copy link

This adds a new ContainerExecutor called DockerContainerExecutor.
This executor launches a container in a docker container, providing
a full filesystem namespace and software isolation for the container.

@ashahab-altiscale ashahab-altiscale force-pushed the aws-yarn-1964-trunk branch 3 times, most recently from 2824dee to 34cd46d Compare September 29, 2014 18:28
This adds a new ContainerExecutor called DockerContainerExecutor.
This executor launches a container in a docker container, providing
a full filesystem namespace and software isolation for the container.
@ashahab-altiscale ashahab-altiscale force-pushed the aws-yarn-1964-trunk branch 2 times, most recently from a7a891d to f8364b7 Compare October 1, 2014 06:07
mekasone pushed a commit to mekasone/hadoop that referenced this pull request Feb 19, 2017
@OneCricketeer
Copy link

Should probably be closed?

Superseded by https://issues.apache.org/jira/browse/YARN-5388

@aajisaka
Copy link
Member

This issue has been fixed. Closing.

@aajisaka aajisaka closed this Jan 24, 2019
qinghui-xu pushed a commit to qinghui-xu/hadoop that referenced this pull request Feb 4, 2022
…based on ACL during upgrade (apache#6)

This commit is only useful to perform the upgrade from 2 to 3. Once the upgrade is finalized, this specific code can (and should) be removed. See below for detailed explanation.

In HDP2, when an application was assigned to a queue through acl queue mappings, it was done at the CapacityScheduler level and not modifying the ApplicationSubmissionContext. Because of this, the application was serialized in the ZKStateStore with the queue it was submitted on at submit time, which is 'default' (we ask user not to decalre the queue but to let acl queue mappings do the job).
It was not a problem for the RM v2, because even if it read the queue default, it would eventually place it on the correct queue.

However, in HDP3, this mechanism has changed and has been rationalized through specific classes and no more the CapacityScheduler (code is a lot cleaner by the way). As a result, queue placement is evaluated before the application is completly submitted. Thus, RM v3 will serialize the final queue to which the application was assigned. But it means that with v3, at restart, the RM will read the queue field that was serialized in the state store and try to place the queue on it. It will not reevaluate the acl queue mapping.

When we upgrade from v2 to v3, the RM will read a lot of application placed on queue default and not try to perform acl queue mapping. Since there is no queue default, teh RM will KILL all the applications that were running.

The fix consists in detecting that the queue returned from the state store is 'default' and if so, evaluate the placement of the application, allowing migration without killing existing apps. Once all applciations have been started/serialized again (through app state changes) in the ZkStateStore, this code has no value anymore.

Co-authored-by: William Montaz <w.montaz@criteo.com>
passaro referenced this pull request in passaro/hadoop Oct 7, 2022
Fix bytes range header format
saxenapranav referenced this pull request in saxenapranav/hadoop Mar 13, 2023
fix namespace fetch for hns account
Yifan122 added a commit to Yifan122/hadoop-apache that referenced this pull request Apr 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants