Created 09-14-2017 05:30 AM
Is there a way to programatically force a configuration redeploy/refresh?
We spin up lots of cluster instances from AWS AMIs that have Cloudera preinstalled, and we're manually having to go into the UI to accomplish this.
Thanks.
Created 09-14-2017 06:08 AM
You can use the python/or curl to achieve this.
Cluster wide [0]
example using curl curl -X POST -u admin:admin -H "Content-Type:application/json" http://cm-hostname:port/api/v17/clusters/{clusterName}/commands/deployClientConfig
Service/role client config [1]
[0]
https://github.com/cloudera/cm_api/blob/master/python/src/cm_api/endpoints/clusters.py#L292-L298
# During restart of the cluster
https://github.com/cloudera/cm_api/blob/master/python/src/cm_api/endpoints/clusters.py#L263-L281
[1]
https://github.com/cloudera/cm_api/blob/master/python/src/cm_api/endpoints/services.py#L867-L874
Created 09-18-2017 01:01 PM
Is this method supported with Cloudera Express 5.6.0?
Created 09-18-2017 01:18 PM
It should, have you noticed otherwise?
Created 09-19-2017 07:55 AM
Using this url: http://172.31.5.254:7180/api/v17/clusters/Cluster%201/commands/deployClientConfig, I'm getting a 404.
Created 09-19-2017 08:10 AM
Perhaps /v17/ isn't applicable for your version of CM - check the /api/version endpoint and see what version your CM supports/returns with.
Here's a table that map version of CM API to CM version
Created 09-19-2017 09:45 AM
I looks like I'm running CM 5.6, which isn't listed in the mapping table you refer to.
However, I tried different API versions using the following url: http://172.31.5.254:7180/api/v1/clusters/Cluster%201/services/hdfs, and got this back:
{
"name" : "hdfs",
"type" : "HDFS",
"clusterRef" : {
"clusterName" : "cluster"
},
"serviceUrl" : "http://172.31.5.254:7180/cmf/serviceRedirect/hdfs",
"serviceState" : "STARTED",
"healthSummary" : "GOOD",
"healthChecks" : [ {
"name" : "HDFS_BLOCKS_WITH_CORRUPT_REPLICAS",
"summary" : "GOOD"
}, {
"name" : "HDFS_CANARY_HEALTH",
"summary" : "GOOD"
}, {
"name" : "HDFS_DATA_NODES_HEALTHY",
"summary" : "GOOD"
}, {
"name" : "HDFS_FREE_SPACE_REMAINING",
"summary" : "GOOD"
}, {
"name" : "HDFS_HA_NAMENODE_HEALTH",
"summary" : "GOOD"
}, {
"name" : "HDFS_MISSING_BLOCKS",
"summary" : "GOOD"
}, {
"name" : "HDFS_UNDER_REPLICATED_BLOCKS",
"summary" : "BAD"
} ],
"configStale" : false
So V1 is responding to something at least, but it maps to CM 4.0, which doesn't make any sense.
Created on 09-19-2017 09:52 AM - edited 09-19-2017 09:57 AM
Quote: However, I tried different API versions using the following url: http://172.31.5.254:7180/api/v1
Based on the documentation linked previously, the endpoint you're trying to use was "Added in v3:"
With regards to the version check http://172.31.5.254:7180/api/version - the returned output can be then used in http://172.31.5.254:7180/api/v...
In addition this is a REST POST, not a GET, the expected response Body after the POST is documented here [0]
Let me know if this helps
Created 09-19-2017 12:55 PM
Thanks, I was able to make all the calls I needed to redeploy the configuration and restart everything on the command line.