You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Dmitry Lysnichenko (JIRA)" <ji...@apache.org> on 2014/09/15 22:33:33 UTC
[jira] [Updated] (AMBARI-7317) Add "exclusive" flag to custom
command/custom action requests
[ https://issues.apache.org/jira/browse/AMBARI-7317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dmitry Lysnichenko updated AMBARI-7317:
---------------------------------------
Description:
The issue is that Update Nagios request may be executed in parallel with start/stop requests in some cases. If Nagios host does not belong to a set of hosts that are affected by start/stop requests, then API user may be able to get a race condition and (sometimes) fake alerts.
Here is an example scenario:
request to start some service host component is issued
request to disable MM for host component is issued
if host component is not located at the same host with Nagios server, both requests are executed in parallel
there is a good chance that the request to disable MM is executed earlier than other request
there is a small chance that Nagios service check for a host component is run before host component is actually started. As a result, administrator gets a 'fantom' alert
It seems that the straightforward solution for both issues is to implement some flag (like exclusive=true) that would be available for custom actions/custom commands. The flag would forbid running request in parallel with other requests. This flag would be used when issuing Update Nagios request. As a result, race condition would not be possible.
Request example:
{code}
curl 'http://vm-6.vm:8080/api/v1/clusters/cc/requests' -H 'X-Requested-By: X-Requested-By' --data '{"RequestInfo":{"command":"RESTART","context":"Restart all components on vm-6.vm","exclusive":"true","operation_level":{"level":"HOST","cluster_name":"cc"}},"Requests/resource_filters":[{"service_name":"HDFS","component_name":"DATANODE","hosts":"vm-6.vm"},{"service_name":"GANGLIA","component_name":"GANGLIA_MONITOR","hosts":"vm-6.vm"},{"service_name":"HDFS","component_name":"HDFS_CLIENT","hosts":"vm-6.vm"},{"service_name":"MAPREDUCE2","component_name":"MAPREDUCE2_CLIENT","hosts":"vm-6.vm"},{"service_name":"ZOOKEEPER","component_name":"ZOOKEEPER_CLIENT","hosts":"vm-6.vm"},{"service_name":"ZOOKEEPER","component_name":"ZOOKEEPER_SERVER","hosts":"vm-6.vm"}]}' -u admin:admin
{code}
was:
The issue is that Update Nagios request may be executed in parallel with start/stop requests in some cases. If Nagios host does not belong to a set of hosts that are affected by start/stop requests, then API user may be able to get a race condition and (sometimes) fake alerts.
Here is an example scenario:
request to start some service host component is issued
request to disable MM for host component is issued
if host component is not located at the same host with Nagios server, both requests are executed in parallel
there is a good chance that the request to disable MM is executed earlier than other request
there is a small chance that Nagios service check for a host component is run before host component is actually started. As a result, administrator gets a 'fantom' alert
It seems that the straightforward solution for both issues is to implement some flag (like exclusive=true) that would be available for custom actions/custom commands. The flag would forbid running request in parallel with other requests. This flag would be used when issuing Update Nagios request. As a result, race condition would not be possible.
> Add "exclusive" flag to custom command/custom action requests
> -------------------------------------------------------------
>
> Key: AMBARI-7317
> URL: https://issues.apache.org/jira/browse/AMBARI-7317
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
> Affects Versions: 1.7.0
> Reporter: Dmitry Lysnichenko
> Assignee: Dmitry Lysnichenko
> Fix For: 1.7.0
>
>
> The issue is that Update Nagios request may be executed in parallel with start/stop requests in some cases. If Nagios host does not belong to a set of hosts that are affected by start/stop requests, then API user may be able to get a race condition and (sometimes) fake alerts.
> Here is an example scenario:
> request to start some service host component is issued
> request to disable MM for host component is issued
> if host component is not located at the same host with Nagios server, both requests are executed in parallel
> there is a good chance that the request to disable MM is executed earlier than other request
> there is a small chance that Nagios service check for a host component is run before host component is actually started. As a result, administrator gets a 'fantom' alert
> It seems that the straightforward solution for both issues is to implement some flag (like exclusive=true) that would be available for custom actions/custom commands. The flag would forbid running request in parallel with other requests. This flag would be used when issuing Update Nagios request. As a result, race condition would not be possible.
> Request example:
> {code}
> curl 'http://vm-6.vm:8080/api/v1/clusters/cc/requests' -H 'X-Requested-By: X-Requested-By' --data '{"RequestInfo":{"command":"RESTART","context":"Restart all components on vm-6.vm","exclusive":"true","operation_level":{"level":"HOST","cluster_name":"cc"}},"Requests/resource_filters":[{"service_name":"HDFS","component_name":"DATANODE","hosts":"vm-6.vm"},{"service_name":"GANGLIA","component_name":"GANGLIA_MONITOR","hosts":"vm-6.vm"},{"service_name":"HDFS","component_name":"HDFS_CLIENT","hosts":"vm-6.vm"},{"service_name":"MAPREDUCE2","component_name":"MAPREDUCE2_CLIENT","hosts":"vm-6.vm"},{"service_name":"ZOOKEEPER","component_name":"ZOOKEEPER_CLIENT","hosts":"vm-6.vm"},{"service_name":"ZOOKEEPER","component_name":"ZOOKEEPER_SERVER","hosts":"vm-6.vm"}]}' -u admin:admin
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)