[
https://issues.apache.org/jira/browse/YARN-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16424424#comment-16424424
]
Eric Yang commented on YARN-7939:
---------------------------------
Base on patch 3 and design document, the upgrade logic is performed as:
PUT on /app/v1/services/[service_name]
{code:java}
{
"name": "abc",
"version" : "v2",
"state": "UPGRADING",
"components" :
[
{
"name": "ping",
"number_of_containers": 2,
"artifact": {
"id": "hadoop/centos:latest",
"type": "DOCKER"
},
"launch_command": "sleep 1200000",
"resource": {
"cpus": 1,
"memory": "256"
}
}
]
}
{code}
Then invoke the per instance upgrade API:
PUT on
/app/v1/services/[service-name]/components/[component-name]/component-instances/[component-instance-name]
{code:java}
{
"state":"UPGRADING",
"component_instance_name":"ping-0"
}
{code}
If a component requires upgrade artifact, is the new artifact id to be included
in the first REST API call?
I am getting this exception when calling the first REST API:
{code}
HTTP/1.1 404 Not Found
Date: Tue, 03 Apr 2018 18:32:01 GMT
Cache-Control: no-cache
Expires: Tue, 03 Apr 2018 18:32:01 GMT
Date: Tue, 03 Apr 2018 18:32:01 GMT
Pragma: no-cache
WWW-Authenticate: Negotiate
YGoGCSqGSIb3EgECAgIAb1swWaADAgEFoQMCAQ+iTTBLoAMCARKiRARCavlOrzh61ik/SAL9Qe9WXzKoJV6toZJAcrbRvvKWr1K3j6mxuBShzcOW9e0VJTNX4d8ThIaxXhD5YjE2WNJRttJn
Set-Cookie:
hadoop.auth="u=hbase&p=hbase/eyang-1.openstacklo...@example.com&t=kerberos-dt&e=1522816321142&s=DqZ2h9xMTVvJy8rdUfxZUVw6wtYl1b72go4XcmedjJU=";
Path=/; Domain=openstacklocal; HttpOnly
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
Content-Type: application/json;charset=utf-8
Transfer-Encoding: chunked
{"exception":"UnrecognizedPropertyException","message":"Unrecognized field
\"component_instance_name\" (class
org.apache.hadoop.yarn.service.api.records.Service), not marked as ignorable
(17 known properties: \"number_of_running_containers\", \"lifetime\",
\"kerberos_principal\", \"name\", \"uri\", \"resource\", \"state\",
\"artifact\", \"components\", \"version\", \"launch_time\", \"id\",
\"description\", \"quicklinks\", \"queue\", \"configuration\",
\"placement_policy\"])\n at [Source:
(org.eclipse.jetty.server.HttpInputOverHTTP); line: 1, column: 53] (through
reference chain:
org.apache.hadoop.yarn.service.api.records.Service[\"component_instance_name\"])","javaClassName":"com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException"}[hbase@eyang-1
hadoop-3.2.0-SNAPSHOT]$ vi /tmp/u1.json
{code}
It appears that the json must include component_instance_name, which means the
JSON that we submit back must be the state JSON instead of spec json.
Container instances may change between user download the state JSON, and
calling upgrade command, is it really necessary to upgrade by instance instead
of by component? I think this approach may possibly introduce out of sync
situation to attempt to upgrade on non-existed instances.
> Yarn Service Upgrade: add support to upgrade a component instance
> ------------------------------------------------------------------
>
> Key: YARN-7939
> URL: https://issues.apache.org/jira/browse/YARN-7939
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Chandni Singh
> Assignee: Chandni Singh
> Priority: Major
> Attachments: YARN-7939.001.patch, YARN-7939.002.patch,
> YARN-7939.003.patch
>
>
> Yarn core supports in-place upgrade of containers. A yarn service can
> leverage that to provide in-place upgrade of component instances. Please see
> YARN-7512 for details.
> Will add support to upgrade a single component instance first and then
> iteratively add other APIs and features.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
