hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gour Saha (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
Date Tue, 17 Oct 2017 20:27:00 GMT

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

Gour Saha commented on YARN-7217:

Do we need a flex operation without restart service? The answer is likely no. There are 3
services (Datanode, NodeManager, HBase region server) that can add slave nodes without restarting
masters. The majority of use case for changing node count will result in configuration changes
and force restart. Majority of software follow the second model to make config changes, then
restart services. This ensure the change request is repeatable. Hence, the need to support
flex operation without configuration change would be greatly reduced.
Scale up and scale down of a specific version of a running service is the most important feature
of an enterprise-grade service (pay only for what you use, financial web-app services scaled
up during the day and scaled down during the night to make way for batch processes, etc.).
Configuration changes or newer version of the service falls into the bucket of an upgrade.
In fact, Slider supports the notion of rolling-upgrade of a service or specific components
of a service in a service-owner defined orchestrated fashion, such that to the end-user the
service never stops running. There was never a need to stop the service as a whole, unless
you ran out of IT budget.

> PUT method for update service for Service API doesn't function correctly
> ------------------------------------------------------------------------
>                 Key: YARN-7217
>                 URL: https://issues.apache.org/jira/browse/YARN-7217
>             Project: Hadoop YARN
>          Issue Type: Task
>          Components: api, applications
>            Reporter: Eric Yang
>            Assignee: Eric Yang
>         Attachments: YARN-7217.yarn-native-services.001.patch, YARN-7217.yarn-native-services.002.patch
> The PUT method for updateService API provides multiple functions:
> # Stopping a service.
> # Start a service.
> # Increase or decrease number of containers.
> The overloading is buggy depending on how the configuration should be applied.
> Scenario 1
> A user retrieves Service object from getService call, and the Service object contains
state: STARTED.  The user would like to increase number of containers for the deployed service.
 The JSON has been updated to increase container count.  The PUT method does not actually
increase container count.
> Scenario 2
> A user retrieves Service object from getService call, and the Service object contains
state: STOPPED.  The user would like to make a environment configuration change.  The configuration
does not get updated after PUT method.
> This is possible to address by rearranging the logic of START/STOP after configuration
update.  However, there are other potential combinations that can break PUT method.  For example,
user like to make configuration changes, but not yet restart the service until a later time.
> The alternative is to separate the PUT method into PUT method for configuration vs status.
 This increase the number of action that can be performed.  New API could look like:
> {code}
> @PUT
> /ws/v1/services/[service_name]/config
> Request Data:
> {
>   "name":"[service_name]",
>   "number_of_containers": 5
> }
> {code}
> {code}
> @PUT
> /ws/v1/services/[service_name]/state
> Request data:
> {
>   "name": "[service_name]",
>   "state": "STOPPED|STARTED"
> }
> {code}

This message was sent by Atlassian JIRA

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

View raw message