[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210347#comment-16210347 ] Jian He commented on YARN-7217: --- Is this patch not allowing flex while app is running ? > 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, > YARN-7217.yarn-native-services.003.patch, > YARN-7217.yarn-native-services.004.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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210340#comment-16210340 ] Jian He commented on YARN-7217: --- [~eyang], Some assumption of the jira is not applicable now, since the flex functionality is removed from the "/ws/v1/services/[service_name]" endpoint. Can you update the jira description accordingly and also provide a description of what the patch does ? > 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, > YARN-7217.yarn-native-services.003.patch, > YARN-7217.yarn-native-services.004.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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210057#comment-16210057 ] Hadoop QA commented on YARN-7217: - | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s{color} | {color:blue} Docker mode activated. {color} | | {color:red}-1{color} | {color:red} docker {color} | {color:red} 0m 11s{color} | {color:red} Docker failed to build yetus/hadoop:0de40f0. {color} | \\ \\ || Subsystem || Report/Notes || | JIRA Issue | YARN-7217 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12892892/YARN-7217.yarn-native-services.004.patch | | Console output | https://builds.apache.org/job/PreCommit-YARN-Build/18012/console | | Powered by | Apache Yetus 0.6.0-SNAPSHOT http://yetus.apache.org | This message was automatically generated. > 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, > YARN-7217.yarn-native-services.003.patch, > YARN-7217.yarn-native-services.004.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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16208504#comment-16208504 ] Hadoop QA commented on YARN-7217: - | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s{color} | {color:blue} Docker mode activated. {color} | | {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 6s{color} | {color:red} YARN-7217 does not apply to yarn-native-services. Rebase required? Wrong Branch? See https://wiki.apache.org/hadoop/HowToContribute for help. {color} | \\ \\ || Subsystem || Report/Notes || | JIRA Issue | YARN-7217 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12892694/YARN-7217.yarn-native-services.003.patch | | Console output | https://builds.apache.org/job/PreCommit-YARN-Build/17996/console | | Powered by | Apache Yetus 0.6.0-SNAPSHOT http://yetus.apache.org | This message was automatically generated. > 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, > YARN-7217.yarn-native-services.003.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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16208278#comment-16208278 ] Eric Yang commented on YARN-7217: - [~billie.rinaldi] A noble idea doesn't always translate to reality. Is it possible to add a standby namenode without restart datanode? Is it possible to add another resource manager without restart node manager? Is it possible to add another Hive server2 without restart Knox for load balance? All above questions have the same answer, no. Hadoop have spent significant 12 years of resources to ensure rpc call retries and elastic datanode can happen. In the recent years, Ambari has been invented to ensure Hadoop configuration are recorded before service operation are performed for serviceability. However, most applications will not receive the same amount of investment like Hadoop in developing reliability and serviceability. Therefore, I do not know if flex without restart would be deem as important as it was once promised. Please note that, the current PUT method retains flex operation as it was written. It only provide additional end point to record number of container needs to be increased or decreased in the event of service restart. Service can resume with the same number of containers prior to stop. Perhaps, we can add a flag to Service object in component section. A flag to indicate if the component can increase/decrease nodes without restart. This will be an hint to backend to allow increase node count without restart. This helps to keep existing slider flex functionality for HBase Region server and new emerging application. Does this sound like a reasonable enhancement? > 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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ 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: - {quote} 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. {quote} 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 (v6.4.14#64029) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16208228#comment-16208228 ] Billie Rinaldi commented on YARN-7217: -- bq. Flex operation was implemented sub-optimally in Slider. i.e. Increased node count for HBase Region server, stop the service, and resume the service. This is not the case. The service is not stopped when flexing an application. The flex operation can be performed while the app is running and it will take effect immediately, or it can be performed while the app is stopped, in which case it will take effect on the next start. It is not acceptable to require stopping the application before flexing takes effect. > 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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16208192#comment-16208192 ] Eric Yang commented on YARN-7217: - [~gsaha] said: {quote} Are you saying that the API will not support flexing of no of containers when the service is running? {quote} Flex operation was implemented sub-optimally in Slider. i.e. Increased node count for HBase Region server, stop the service, and resume the service. Should the service resume from 4 nodes that was initially started or 10 nodes that was later increased? While Slider had a noble idea to have flex operation, but an operation without storing configuration can cause operation hazard because the operation become non-repeatable. YARN-7216 is proposed to decouple configuration changes and performing an operation. This JIRA propose to separate out PUT method for updateService into two calls for config changes, and service operation. This will provide more insights into over all transaction, and provide ability to reproduce. 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. > 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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206827#comment-16206827 ] Hadoop QA commented on YARN-7217: - | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 16s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s{color} | {color:green} The patch appears to include 32 new or modified test files. {color} | || || || || {color:brown} yarn-native-services Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 2m 2s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 23m 38s{color} | {color:green} yarn-native-services passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 23m 21s{color} | {color:green} yarn-native-services passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m 42s{color} | {color:green} yarn-native-services passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 3m 36s{color} | {color:green} yarn-native-services passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 20m 5s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s{color} | {color:blue} Skipped patched modules with no Java source: hadoop-project {color} | | {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 6s{color} | {color:red} hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api in yarn-native-services has 1 extant Findbugs warnings. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 2s{color} | {color:green} yarn-native-services passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 58s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 28s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 20m 55s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 20m 55s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 2m 56s{color} | {color:orange} root: The patch generated 14 new + 235 unchanged - 8 fixed = 249 total (was 243) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 3m 56s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 21s{color} | {color:green} The patch has no ill-formed XML file. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 34s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s{color} | {color:blue} Skipped patched modules with no Java source: hadoop-project {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 9m 37s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 13s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 19s{color} | {color:green} hadoop-project in the patch passed. {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 49s{color} | {color:green} hadoop-yarn-api in the patch passed. {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 17s{color} | {color:green} hadoop-yarn-common in the patch passed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 35s{color} | {color:red} hadoop-yarn-services-core in the patch failed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 34s{color} | {color:red} hadoop-yarn-services-api i
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ 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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206108#comment-16206108 ] Eric Yang commented on YARN-7217: - The unit tests failure are not related to this patch. It looks like the recent commit or rebase yarn-native-services branch broked yarn-native-services branch. > 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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204378#comment-16204378 ] Hadoop QA commented on YARN-7217: - | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 16s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s{color} | {color:green} The patch appears to include 32 new or modified test files. {color} | || || || || {color:brown} yarn-native-services Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 2m 5s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 17m 20s{color} | {color:green} yarn-native-services passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 17m 6s{color} | {color:green} yarn-native-services passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m 9s{color} | {color:green} yarn-native-services passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m 58s{color} | {color:green} yarn-native-services passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 15m 49s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s{color} | {color:blue} Skipped patched modules with no Java source: hadoop-project {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 39s{color} | {color:green} yarn-native-services passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 48s{color} | {color:green} yarn-native-services passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m 2s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 34s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 13m 51s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 13m 51s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 2m 34s{color} | {color:orange} root: The patch generated 28 new + 29 unchanged - 8 fixed = 57 total (was 37) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m 31s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 16s{color} | {color:green} The patch has no ill-formed XML file. {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 51s{color} | {color:red} patch has errors when building and testing our client artifacts. {color} | | {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s{color} | {color:blue} Skipped patched modules with no Java source: hadoop-project {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 22s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 23s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 23s{color} | {color:green} hadoop-project in the patch passed. {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 8s{color} | {color:green} hadoop-yarn-common in the patch passed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 1m 21s{color} | {color:red} hadoop-yarn-services-core in the patch failed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 1m 22s{color} | {color:red} hadoop-yarn-services-api in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 49s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:b
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204375#comment-16204375 ] Eric Yang commented on YARN-7217: - [~gsaha] {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} There is a bug in the code. {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? {quote} Yes, pause application should be supported in the REST API. It is a valid use case to allow pause of the application by running slider stop, and resume the application later with a different YARN application ID,andt brand new set of containers. {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} Yes, GET is also implemented in the current patch. I incorporated patch for YARN-7216 in this patch to reduce logistic work. {quote} Also, the patch contains solr specific changes and cannot be reviewed in its current state. {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. > 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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204284#comment-16204284 ] Gour Saha commented on YARN-7217: - Also, the patch contains solr specific changes and cannot be reviewed in its current state. > 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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ 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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16172359#comment-16172359 ] Eric Yang commented on YARN-7217: - [~jianhe] Agree, spec will make this less 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 > > 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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7217) PUT method for update service for Service API doesn't function correctly
[ https://issues.apache.org/jira/browse/YARN-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16172355#comment-16172355 ] Jian He commented on YARN-7217: --- Thanks Eric, how about call it spec instead of config ? because the spec itself has a config filed which will be confusing {code} @PUT /ws/v1/services/[service_name]/spec {code} In request body, the name field can be an optional field, since it can be retrieved from URL path > 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 > > 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-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org