[
https://issues.apache.org/jira/browse/YARN-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566127#comment-16566127
]
Eric Yang commented on YARN-8160:
---------------------------------
What to expect when upgrading a docker container from YARN managed service:
User specified input JSON can have changes to the following:
- Version number
- Resource parameters can be changed, this includes the number of cpu and
memory allocated.
- Environment variables
- Configuration templates
- Mounting locations
What YARN service might change:
- Location of the docker container launched. YARN will try best effort to
relaunch container on the same node manager. If container failed to relaunch.
The container might moved to a different node.
- Docker may give out original IP address to another container while the
upgrade is happening, the new instance might be started with a new IP address.
- Container Log. If relaunch is successful, the log is appended to the same
stdout.txt and stderr.txt. However, if container restart on a different disk
or different node. The log content might be truncated to the current instance.
What YARN service will not change:
- Container ID
- Hostname of container
- Application name
- Name of all components
Data stored in node manager local directory is not guarantee to survive
upgrade. For stateful data, it is best to store in HDFS, or mounted location
out side of node manager local directory. Docker image should be designed to
handle data conversion to simplify the upgrade process.
The current reInitializeContainer API can work for most of config changes. As
long as the regenerated .cmd file containers proper parameter format that can
be used by container-executor. Image download is handled when
container-executor launches "docker run". Therefore, we don't need to worry
about logic to break docker image download into separate steps at this time.
> Yarn Service Upgrade: Support upgrade of service that use docker containers
> ----------------------------------------------------------------------------
>
> Key: YARN-8160
> URL: https://issues.apache.org/jira/browse/YARN-8160
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Chandni Singh
> Assignee: Chandni Singh
> Priority: Major
> Labels: Docker
>
> Ability to upgrade dockerized yarn native services.
> Ref: YARN-5637
> *Background*
> Container upgrade is supported by the NM via {{reInitializeContainer}} api.
> {{reInitializeContainer}} does *NOT* change the ContainerId of the upgraded
> container.
> NM performs the following steps during {{reInitializeContainer}}:
> - kills the existing process
> - cleans up the container
> - launches another container with the new {{ContainerLaunchContext}}
> NOTE: {{ContainerLaunchContext}} holds all the information that needs to
> upgrade the container.
> With {{reInitializeContainer}}, the following does *NOT* change
> - container ID. This is not created by NM. It is provided to it and here RM
> is not creating another container allocation.
> - {{localizedResources}} this stays the same if the upgrade does *NOT*
> require additional resources IIUC.
>
> The following changes with {{reInitializeContainer}}
> - the working directory of the upgraded container changes. It is *NOT* a
> relaunch.
> *Changes required in the case of docker container*
> - {{reInitializeContainer}} seems to not be working with Docker containers.
> Investigate and fix this.
> - [Future change] Add an additional api to NM to pull the images and modify
> {{reInitializeContainer}} to trigger docker container launch without pulling
> the image first which could be based on a flag.
> -- When the service upgrade is initialized, we can provide the user with
> an option to just pull the images on the NMs.
> -- When a component instance is upgrade, it calls the
> {{reInitializeContainer}} with the flag pull-image set to false, since the NM
> will have already pulled the images.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
