[
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: [email protected]
For additional commands, e-mail: [email protected]
