Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Ambari REST API request not appearing in "Background Operations"

avatar
Guru

I am trying to startup services using the REST API on a newly-installed cluster named "horton" using Ambari 2.2.0.0. The following command used to work on prior versions of Ambari, but now it returns an error:

$ curl -u admin:admin -i -H 'X-Requested-By: ambari' -X PUT -d '{"RequestInfo": {"context" :"Start HDFS"}, "Body": {"ServiceInfo": {"state": "STARTED"}}}' http://namenode:8080/api/v1/clusters/horton/services/HDFS 

The response I get back is:

HTTP/1.1 200 OK
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
User: admin
Set-Cookie: AMBARISESSIONID=zs3kuvep5dte6gie9q6lb5u5;Path=/;HttpOnly
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/plain
Content-Length: 0
Server: Jetty(8.1.17.v20150415)

Any help would be greatly appreciated. Thanks!

1 ACCEPTED SOLUTION

avatar
Guru

OK - I think I answered my own question: sorry for the confusion. Ambari 2.2.x appears to be smarter than its predecessors. The reason my initial REST request "failed" was because HDFS was already running, so Ambari simply ignored the request.

REST API requests used to always show up in the "Background Operations" window, but now they do not if the service doesn't need starting. That decision seems fine with me - just caught me off guard!

Thanks for providing feedback.

-Rich

View solution in original post

6 REPLIES 6

avatar

This should be against the requests endpoint, e.g., http://ambariserver:8080/api/v1/clusters/horton/requests

avatar
Guru

Changing "services" to "requests" resulted in a bad request - maybe I need to change something else? I have never started a service using "requests" before:

HTTP/1.1 400 Bad Request

{
  "status" : 400,
  "message" : "org.apache.ambari.server.controller.spi.UnsupportedPropertyException: The properties [ServiceInfo/state] specified in the request or predicate are not supported for the resource type Request."
}

avatar

That response does not look like an error. You are getting back a success code:

HTTP/1.1 200 OK

The "deny" header value you see is for web clients to indicate that the response is not to be displayed in a browser frame. In this context, the header does not apply. Due to the way Ambari is structured, it does not particularly know what the expected destination of the response is, so the header is sent no matter what. This goes for the X-XSS-Protection header as well.

X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

avatar
Guru

If the request is not being denied, then my question should be changed. The REST request above used to work - but now on Ambari 2.2 it does not have any affect. Here is something else that is interesting - when I try to start all services using the following request:

curl -u admin:admin -i -H 'X-Requested-By: ambari' -X PUT -d '{"RequestInfo": {"context" :"Start all services"}, "Body": {"ServiceInfo": {"state": "STARTED"}}}' http://namenode:8080/api/v1/clusters/horton/services?ServiceInfo

this request gets accepted by Ambari, but here is what it does:

1302-screen-shot-2016-01-12-at-30054-pm.png

That image is not cropped - all that happens is Pig, Slider, Sqoop and the Tez Client get installed. What I expected to see was all of my services starting. Again, this is based on the curl command above that I have used with Ambari 2.1 regularly.

avatar
Guru

OK - I think I answered my own question: sorry for the confusion. Ambari 2.2.x appears to be smarter than its predecessors. The reason my initial REST request "failed" was because HDFS was already running, so Ambari simply ignored the request.

REST API requests used to always show up in the "Background Operations" window, but now they do not if the service doesn't need starting. That decision seems fine with me - just caught me off guard!

Thanks for providing feedback.

-Rich

avatar

Note that the requests don't work if the service is in maintenance mode. So to be safe, I usually disable it before interacting with the service via API. This worked for me. Change the exported variables accordingly for your setup

export SERVICE=HDFS
export PASSWORD=admin
export AMBARI_HOST=localhost
export CLUSTER=Sandbox

#get status
curl -u admin:$PASSWORD -i -H 'X-Requested-By: ambari' -X GET http://$AMBARI_HOST:8080/api/v1/clusters/$CLUSTER/services/$SERVICE

#disable maintenance mode
curl -u admin:$PASSWORD -i -H 'X-Requested-By: ambari' -X PUT -d '{"RequestInfo": {"context" :"Remove HDFS from maintenance mode"}, "Body": {"ServiceInfo": {"maintenance_state": "OFF"}}}' http://$AMBARI_HOST:8080/api/v1/clusters/$CLUSTER/services/HDFS

#stop service
curl -u admin:$PASSWORD -i -H 'X-Requested-By: ambari' -X PUT -d '{"RequestInfo": {"context" :"Stop $SERVICE via REST"}, "Body": {"ServiceInfo": {"state": "INSTALLED"}}}' http://$AMBARI_HOST:8080/api/v1/clusters/$CLUSTER/services/$SERVICE

#start service
curl -u admin:$PASSWORD -i -H 'X-Requested-By: ambari' -X PUT -d '{"RequestInfo": {"context" :"Start $SERVICE via REST"}, "Body": {"ServiceInfo": {"state": "STARTED"}}}' http://$AMBARI_HOST:8080/api/v1/clusters/$CLUSTER/services/$SERVICE