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 Mon, 16 Oct 2017 23:31:00 GMT

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

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

{quote}
For changing number of containers with in a service, the api call must invoke:
1. Update service configuration
2. Stop existing service
3. Start service
{quote}
Are you saying that the API will not support flexing of no of containers when the service
is running?

{quote}
The patch allows the configuration to be stored in Solr for faster search and retrieval time.
There is a on/off flag to use Slor as backend. When solr storage backend is disabled (default),
it will look for spec in HDFS.
{quote}
[~eyang], the description of the jira says "PUT method for update service for Service API
doesn't function correctly". It is about functionality and not performance. Please file a
separate jira for performance & fast search and move the Solr changes there as a separate
patch. Additionally, the patch for YARN-7216 contains the exact same Solr code that is here
in this patch as well, which makes it even more confusing.

> 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
(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


Mime
View raw message