[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly

["Gour Saha (JIRA)" <ji...@apache.org>]

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

Gour Saha commented on YARN-7217:
---------------------------------

{quote}
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.
{quote}
What do you mean by it does not increase the count? Are you saying there is a bug in the code, or are you saying that it should not increase container count?

{quote}
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.
{quote}
Modifying service config for a service in STOPPED state is not supported via the REST API. It is supported in classic Slider though. Are you saying you want to support this in REST API?

bq. For example, user like to make configuration changes, but not yet restart the service until a later time.
Not sure if I understand this. Today if a spec change is requested for a running service, it does not reflect until the user does an orchestrated upgrade (which restarts individual containers). This is supported in classic Slider, and needs equivalent support in REST API which is not implemented yet.

If you are saying you want to support the below -
{quote}
@PUT
/ws/v1/services/\[service_name\]/spec
{quote}
Do you intend to support GET for /ws/v1/services/\[service_name\]/spec as well? If yes, then for a STARTED app, what will GET return - the spec corresponding to the current snapshot of the running app OR the saved spec which might be more recent and has not been reflected to the running state yet? For STOPPED app this is not a problem.

{quote}
@PUT
/ws/v1/services/\[service_name\]/state
Request data:
{
  "state": "STOPPED|STARTED"
}
{quote}
The resource URI has state in the path, so the request data needs some modification to not repeat "state" as a key again.

> 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
>
>
> 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
(v6.4.14#64029)

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