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

Arun Suresh edited comment on YARN-5609 at 9/20/16 5:50 PM:
------------------------------------------------------------

Updating patch, Thanks [~jianhe]..

* Addressed most of your concerns.
* Added some more comments to clarify some assumptions.
* Added testcases to verify that Explicit rollback is still possible AFTER 
upgraded container has been restarted.

bq.  I think this will cause the resources to be re-requested on restart. Even 
though the effect might still be the same, because the resources are already 
localized and the requests will be ignored,  but I think we can still try to 
avoid sending these unnecessary events in case the resource set is large ?
I had intentionally kept it that way (my thinking was that the Tracker will 
then verify that the resources.. directories etc. are still good)...
But I agree with you.. It is inefficient. I've updated patch to make sure that 
in case of rollback and restart, this wont happen.. I've also put some comments 
there.. do take a look and let me know if its fine.


With regard to this:
{noformat} 
    private ReInitializationContext createContextForRollback() {
      if (oldLaunchContext == null) {
        return null;
      } else {
{noformat}
There should not be a NPE, since it is always called in conjunctions with a 
{{container.canRollback()}} which returns true only if _oldLaunchContext_ is 
non null.





was (Author: asuresh):
Updating patch, Thanks [~jianhe]..

* Addressed most of your concerns.
* Added some more comments to clarify some assumptions.
* Added testcases to verify that Explicit rollback is still possible AFTER 
upgraded container has been restarted.

bq.  I think this will cause the resources to be re-requested on restart. Even 
though the effect might still be the same, because the resources are already 
localized and the requests will be ignored,  but I think we can still try to 
avoid sending these unnecessary events in case the resource set is large ?
I had intentionally kept it that way (my thinking was that the Tracker will 
then verify that the resources.. directories etc. are still good)...
But I agree with you.. It is inefficient. I've updated patch to make sure that 
in care of rollback and restart, this wont happen.. do take a look and let me 
know if its fine.


With regard to this:
{noformat} 
    private ReInitializationContext createContextForRollback() {
      if (oldLaunchContext == null) {
        return null;
      } else {
{noformat}
There should not be a NPE, since it is always called in conjunctions with a 
{{container.canRollback()}} which returns true only if _oldLaunchContext_ is 
non null.




> Expose upgrade and restart API in ContainerManagementProtocol
> -------------------------------------------------------------
>
>                 Key: YARN-5609
>                 URL: https://issues.apache.org/jira/browse/YARN-5609
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Arun Suresh
>            Assignee: Arun Suresh
>         Attachments: YARN-5609.001.patch, YARN-5609.002.patch, 
> YARN-5609.003.patch, YARN-5609.004.patch
>
>
> YARN-5620 and YARN-5637 allows an AM to explicitly *upgrade* a container with 
> a new launch context and subsequently *rollback* / *commit* the change on the 
> Container. This can also be used to simply *restart* the Container as well. 
> This JIRA proposes to extend the ContainerManagementProtocol with the 
> following API:
> * *upgradeContainer*
> * *rollbackLastUpgrade*
> * *commitLastUpgrade*
> * *restartContainer*



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

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

Reply via email to