[jira] [Comment Edited] (YARN-5637) Changes in NodeManager to support Container rollback and commit

["Arun Suresh (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/YARN-5637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15501051#comment-15501051 ] 

Arun Suresh edited comment on YARN-5637 at 9/18/16 2:22 PM:
------------------------------------------------------------

Thanks for the review [~vvasudev].
We don't really delete the new ResourceSet when we rollback. To clarify the scenario you mentioned, As part of the upgrade a rogue jar is symlinked into the Container's working directory and added to its CLASSPATH env variable.
I see 2 cases:
# The rogue jar's symlink has over-written the earlier version's symlink. In this case, on rollback, the symlink will be re over-written with the old jar and the relaunched old process will see only the old jar.
# The rogue jar's is a new symlink in the container's working dir. In this case, on rollback, the symlink will still remain in the working dir and still point to the old jar. But since the CLASSPATH will also be reverted to the old CLASSPATH (since it's part of the launch context) which does not contain this new jar... I am guessing it should be fine.

But yeah, we can maybe add more sophistication to actually delete / unlink the new new resources from the working directory on rollback. Let's handle that, as you suggested as part of another JIRA, and lets continue with the current approach as a first cut.

Hope this made sense. If so, I will go ahead and commit this.



was (Author: asuresh):
Thanks for the review [~vvasudev].
We don't really delete the new ResourceSet when we rollback. To clarify the scenario you mentioned, As part of the upgrade a rogue jar is symlinked into the Container's working directory and added to its CLASSPATH env variable.
I see 2 cases:
# The rogue jar's symlink has over-written the earlier version's symlink. In this case, on rollback, the symlink will be re over-written with the old jar and the relaunched old process will see only the old jar.
# The rogue jar's is a new symlink in the container's working dir. In this case, on rollback, the symlink will still remain in the working dir and still point to the old jar. But since the CLASSPATH will also be reverted to the old CLASSPATH which does not contain this new jar... I am guess it should be fine.

But yeah, we can maybe add more sophistication to actually delete / unlink the new new resources from the working directory on rollback. Let's handle that, as you suggested as part of another JIRA, and lets continue with the current approach as a first cut.

Hope this made sense. If so, I will go ahead and commit this.


> Changes in NodeManager to support Container rollback and commit
> ---------------------------------------------------------------
>
>                 Key: YARN-5637
>                 URL: https://issues.apache.org/jira/browse/YARN-5637
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Arun Suresh
>            Assignee: Arun Suresh
>         Attachments: YARN-5637.001.patch, YARN-5637.002.patch, YARN-5637.003.patch, YARN-5637.004.patch, YARN-5637.005.patch, YARN-5637.006.patch, YARN-5637.007.patch
>
>
> YARN-5620 added support for re-initialization of Containers using a new launch Context.
> This JIRA proposes to use the above feature to support upgrade and subsequent rollback or commit of the upgrade.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org