ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitry Lysnichenko (JIRA)" <>
Subject [jira] [Commented] (AMBARI-4782) Error in getting host components with state INSTALL_FAILED
Date Fri, 28 Feb 2014 12:47:19 GMT


Dmitry Lysnichenko commented on AMBARI-4782:

[~mahadev] / [~sumitmohanty] / [~u39kun] 
I think it would be good to change the desired solution. Currently we have an inconsistency
in our API: "state" parameter has a different meaning in request and in responce.   Talked
to UI folks regarding that, they agree that it is an issue, but are not sure how much the
proposed fix will affect the UI.
h2. What is wrong:
HostComponentResourceProvider has two properties defined: "state" and "desired_state". When
we issue a read request like http://vm-3.vm:8080/api/v1/clusters/cc/host_components?HostRoles/state=INSTALL_FAILED
, the "state" parameter is mapped to "desired_state". 
At the same time, "state" property meaning at responce json is a live service state (so-called
current state).
href: "http://vm-3.vm:8080/api/v1/clusters/cc/hosts/vm-3.vm/host_components/HDFS_CLIENT",
HostRoles: {
cluster_name: "cc",
component_name: "HDFS_CLIENT",
host_name: "vm-3.vm",
state: "INSTALLED"
host: {
href: "http://vm-3.vm:8080/api/v1/clusters/cc/hosts/vm-3.vm"
This inconsistency is not obvious and may lead to various issues like state=INSTALL_FAILED
issue mentioned above. So I believe that the right thing would be to remap "state" parameter
to service live state both in requests and responses (and adjust appropriately web-UI  and
any third-party tools if needed). I assume that most party tools will not even notice a difference
because they use "state" parameter as "live state". "current_state" property should not be
added as it will only introduce more confusion. 

> Error in getting host components with state INSTALL_FAILED
> ----------------------------------------------------------
>                 Key: AMBARI-4782
>                 URL:
>             Project: Ambari
>          Issue Type: Task
>          Components: controller, test
>    Affects Versions: 1.3.0
>            Reporter: Dmitry Lysnichenko
>            Assignee: Dmitry Lysnichenko
>             Fix For: 1.5.0
> h2. The problem
> When try to get query on api/v1/clusters/<clustername>/host_components?HostRoles/state=INSTALL_FAILED
> Response is
> { "status" : 400, "message" : "Invalid Request: Invalid arguments, invalid desired state,
desiredState=INSTALL_FAILED" }
> This issue is rooted at the over all issue Ambari has where when "state" is specified
in the API requests it is always interpreted as "desired_state". And INSTALL_FAILED is an
invalid "desired_state". Just fixing the GET calls to interpret request:state as "state" (current
state of a host component) might be the right thing to do but will make the get calls to behave
differently than other calls. For example, request to set all component which are in INSTALL_FAILED
state to INIT (or MAINTENANCE) will not work as expected. 
> h2. The proposal:
> The fix is to distinguish between "current_state" and "desired_state" and promote "current_state"
as a first class query parameter. "state" query parameter will be still mapped to "desired_state"
to maintain backward compatibility.

This message was sent by Atlassian JIRA

View raw message