Auto-redeploy of client configuration...

[#1]

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.

[#2]

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://cloudera.github.io/cm_api/apidocs/v17/path__clusters_-clusterName-_commands_deployClientConf...

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://cloudera.github.io/cm_api/apidocs/v17/path__clusters_-clusterName-_services_-serviceName-_co...

https://github.com/cloudera/cm_api/blob/master/python/src/cm_api/endpoints/services.py#L867-L874

[#3]

Is this method supported with Cloudera Express 5.6.0?

[#4]

It should, have you noticed otherwise?

[#5]

Using this url: http://172.31.5.254:7180/api/v17/clusters/Cluster%201/commands/deployClientConfig, I'm getting a 404.

[#6]

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

http://cloudera.github.io/cm_api/docs/releases/

[#7]

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.

[#8]

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

[0] https://cloudera.github.io/cm_api/apidocs/v17/path__clusters_-clusterName-_services_-serviceName-_co...

[#9]

Thanks, I was able to make all the calls I needed to redeploy the configuration and restart everything on the command line.