[
https://issues.apache.org/jira/browse/YARN-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16586193#comment-16586193
]
Chandni Singh edited comment on YARN-8298 at 8/20/18 4:45 PM:
--------------------------------------------------------------
[~eyang] Please see
{quote}
actionUpgradeExpress computes components order before calling backend. The
logic is to upgrade component by component. Instance order is irrelevant within
a component in this design. I think this match up fine with how we upgrade
services today in Hadoop software.
{quote}
The code which you pasted does not seem to upgrade component by component.
1. The below line finds all the containers that will be sent to AM for upgrades
{code:java}
containersToUpgrade = ServiceApiUtil
.validateAndResolveCompsUpgrade(persistedService, components);
{code}
2. The below request is sent to AM and the AM issues event to upgrade all the
instances
{code}
CompInstancesUpgradeRequestProto.Builder upgradeRequestBuilder =
CompInstancesUpgradeRequestProto.newBuilder();
upgradeRequestBuilder.addAllContainerIds(containerIdsToUpgrade);
{code}
Instances are processing these events asynchronously, so all the instances will
get upgraded without any order guarantees
Having to upgrade component by component could only be supported if we have
support for canceling the upgrade when there is any failure. Also in case the
upgrade is cancelled, we need a way for the user to check the status of the
upgrade.
was (Author: csingh):
[~eyang] Please see
{quote}
actionUpgradeExpress computes components order before calling backend. The
logic is to upgrade component by component. Instance order is irrelevant within
a component in this design. I think this match up fine with how we upgrade
services today in Hadoop software.
{quote}
The code which you pasted does not seem to upgrade component by component.
1. The below line finds all the containers that will be sent to AM for upgrades
{code:java}
containersToUpgrade = ServiceApiUtil
.validateAndResolveCompsUpgrade(persistedService, components);
{code}
2. The below request is sent to AM and the AM issues event to upgrade all the
instances
{code}
CompInstancesUpgradeRequestProto.Builder upgradeRequestBuilder =
CompInstancesUpgradeRequestProto.newBuilder();
upgradeRequestBuilder.addAllContainerIds(containerIdsToUpgrade);
{code}
Having to upgrade component by component could only be supported if we have
support for canceling the upgrade when there is any failure. Also in case the
upgrade is cancelled, we need a way for the user to check the status of the
upgrade.
> Yarn Service Upgrade: Support express upgrade of a service
> ----------------------------------------------------------
>
> Key: YARN-8298
> URL: https://issues.apache.org/jira/browse/YARN-8298
> Project: Hadoop YARN
> Issue Type: Sub-task
> Affects Versions: 3.1.1
> Reporter: Chandni Singh
> Assignee: Chandni Singh
> Priority: Major
> Attachments: YARN-8298.001.patch, YARN-8298.002.patch,
> YARN-8298.003.patch
>
>
> Currently service upgrade involves 2 steps
> * initiate upgrade by providing new spec
> * trigger upgrade of each instance/component
>
> We need to add the ability to upgrade the service in one shot:
> # Aborting the upgrade will not be supported
> # Upgrade finalization will be done automatically.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
