[
https://issues.apache.org/jira/browse/SLIDER-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kyungwan nam updated SLIDER-1265:
---------------------------------
Description:
h2. Problem
Currently, upgrading an app is tightly coupled with YARN container lifecycle.
To upgrade an app, existing YARN container must be released and then new
container would be allocated.
In case of the large cluster which multitude of apps are running, during an
upgrade, getting back resources to the upgrading app is hard to be guaranteed.
Even if new YARN container is allocated finally, It could takes too long time.
It would be harmful for reliable service.
That makes it difficult to change even trivial config.
h2. Proposal
Currently, procedure to upgrade a container is as follows.
* AM send PRE_UPGRADE command to agent.
* AM send STOP command to agent.
* existing YARN container is released due to stopped agent.
* AM ask for a new YARN container / new YARN container is allocated.
* AM launch app with new config/package to the new YARN container.
I propose _--reusecontainer option for slider upgrade_, which upgrade on
existing YARN container.
with _--reusecontainer_, it would be as below.
* AM send PRE_UPGRADE command to agent.
* AM send STOP command to agent.
* AM send INSTALL command to agent.
* AM send START command to agent.
There are some limitation.
* app-package is provisioned by YARN container localization. so, changing
app-package does not work.
* the existing YARN container is kept. so, changing resource specification
like memory does not work.
Even though some limitation, in case of modifying/adding app-specific config,
It makes upgrading app easy.
was:
h2. Problem
Currently, upgrading an app is tightly coupled with YARN container lifecycle.
To upgrade an app, existing YARN container must be released and then new
container would be allocated.
In case of the large cluster which multitude of apps are running, during an
upgrade, getting back resources to the upgrading app is hard to be guaranteed.
Even if new YARN container is allocated finally, It could takes too long time.
It would be harmful for reliable service.
That makes it difficult to change even trivial config.
h2. Proposal
Currently, procedure to upgrade a container is as follows.
* AM send PRE_UPGRADE command to agent.
* AM send STOP command to agent.
* existing YARN container is released due to stopped agent.
* AM ask for a new YARN container / new YARN container is allocated.
* AM launch app with new config/package to the new YARN container.
I propose _--reusecontainer_option for _slider upgrade_, which upgrade on
existing YARN container.
with _--reusecontainer_, it would be as below.
* AM send PRE_UPGRADE command to agent.
* AM send STOP command to agent.
* AM send INSTALL command to agent.
* AM send START command to agent.
There are some limitation.
* app-package is provisioned by YARN container localization. so, changing
app-package does not work.
* the existing YARN container is kept. so, changing resource specification like
memory does not work.
Even though some limitation, in case of modifying/adding app-specific config,
It makes upgrading app easy.
> Support upgrade with reusing YARN container
> -------------------------------------------
>
> Key: SLIDER-1265
> URL: https://issues.apache.org/jira/browse/SLIDER-1265
> Project: Slider
> Issue Type: New Feature
> Reporter: kyungwan nam
> Assignee: kyungwan nam
> Priority: Major
> Attachments: SLIDER-1265.001.patch
>
>
> h2. Problem
> Currently, upgrading an app is tightly coupled with YARN container lifecycle.
> To upgrade an app, existing YARN container must be released and then new
> container would be allocated.
> In case of the large cluster which multitude of apps are running, during an
> upgrade, getting back resources to the upgrading app is hard to be guaranteed.
> Even if new YARN container is allocated finally, It could takes too long
> time.
> It would be harmful for reliable service.
> That makes it difficult to change even trivial config.
> h2. Proposal
> Currently, procedure to upgrade a container is as follows.
> * AM send PRE_UPGRADE command to agent.
> * AM send STOP command to agent.
> * existing YARN container is released due to stopped agent.
> * AM ask for a new YARN container / new YARN container is allocated.
> * AM launch app with new config/package to the new YARN container.
> I propose _--reusecontainer option for slider upgrade_, which upgrade on
> existing YARN container.
> with _--reusecontainer_, it would be as below.
> * AM send PRE_UPGRADE command to agent.
> * AM send STOP command to agent.
> * AM send INSTALL command to agent.
> * AM send START command to agent.
> There are some limitation.
> * app-package is provisioned by YARN container localization. so, changing
> app-package does not work.
> * the existing YARN container is kept. so, changing resource specification
> like memory does not work.
> Even though some limitation, in case of modifying/adding app-specific config,
> It makes upgrading app easy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
