1. Is there a way via the API to force it to update the DecomHosts field with fresh data? There's a slight delay after the decommission process finishes before it is returned in the DecomHosts field of the NAMENODE, which is creating a race condition in my automation (sometimes it doesn't see the decommissioning hosts and just goes ahead and removes the DATANODE before it has finished re-replicating blocks). Are you referring to "DecomNodes"? That is populated through the jmx data from NameNode itself. You may have to add a delay.
2. Where in the API does the UI detect that components have stale configs and need to be restarted? I haven't been able to find that yet. The staleness of config is detected at the level of host components. E.g. http://c6401.ambari.apache.org:8080/api/v1/clusters/c1/hosts/c6401.ambari.apache.org/host_components/RESOURCEMANAGER { "href" : "http://c6401.ambari.apache.org:8080/api/v1/clusters/c1/hosts/c6401.ambari.apache.org/host_components/RESOURCEMANAGER";, "HostRoles" : { ... "stale_configs" : false, "state" : "STARTED", "actual_configs" : { ... specifies what version of config is applied ...} } The host resources reports the desired_config versions - in case you are curious about what is difference. ________________________________ From: Greg Hill <[email protected]> Sent: Sunday, February 08, 2015 7:22 AM To: [email protected] Subject: Ambari API questions 1. Is there a way via the API to force it to update the DecomHosts field with fresh data? There's a slight delay after the decommission process finishes before it is returned in the DecomHosts field of the NAMENODE, which is creating a race condition in my automation (sometimes it doesn't see the decommissioning hosts and just goes ahead and removes the DATANODE before it has finished re-replicating blocks). 2. Where in the API does the UI detect that components have stale configs and need to be restarted? I haven't been able to find that yet. Thanks in advance. Greg
