ServicesResource Resource

GET /clusters/{clusterName}/services

Lists all services registered in the cluster.

POST /clusters/{clusterName}/services

Creates a list of services.

There are typically two service creation strategies:

1. The caller may choose to set up a new service piecemeal, by first creating the service itself (without any roles or configuration), and then create the roles, and then specify configuration.
2. Alternatively, the caller can pack all the information in one call, by fully specifying the fields in the ApiService object, with
   • service config and role type config, and
   • role to host assignment.

POST /clusters/{clusterName}/services

DELETE /clusters/{clusterName}/services/{serviceName}

Deletes a service from the system.

GET /clusters/{clusterName}/services/{serviceName}

Retrieves details information about a service.

GET /clusters/{clusterName}/services/{serviceName}

Retrieves details information about a service.

PUT /clusters/{clusterName}/services/{serviceName}

Updates service information.

This method will update only writable fields of the service information. Currently this only includes the service display name.

Available since API v3.

GET /clusters/{clusterName}/services/{serviceName}/clientConfig

Download a zip-compressed archive of the client configuration, of a specific service. This resource does not require any authentication.

GET /clusters/{clusterName}/services/{serviceName}/commands

List active service commands.

GET /clusters/{clusterName}/services/{serviceName}/commands

List active service commands.

GET /clusters/{clusterName}/services/{serviceName}/commandsByName

Lists all the commands (for CSD based services only) that can be executed by name on the provided service.

Available since API v6.

GET /clusters/{clusterName}/services/{serviceName}/config

Retrieves the configuration of a specific service.

The "summary" view contains only the configured parameters, and configuration for role types that contain configured parameters.

The "full" view contains all available configuration parameters for the service and its role types. This mode performs validation on the configuration, which could take a few seconds on a large cluster (around 500 nodes or more).

PUT /clusters/{clusterName}/services/{serviceName}/config

Updates the service configuration with the given values.

If a value is set in the given configuration, it will be added to the service's configuration, replacing any existing entries. If a value is unset (its value is null), the existing configuration for the attribute will be erased, if any.

Attributes that are not listed in the input will maintain their current values in the configuration.

GET /clusters/{clusterName}/services/{serviceName}/impalaUtilization

Provides the resource utilization of the Impala service as well as the resource utilization per tenant. Only available with Cloudera Manager Enterprise Edition.

GET /clusters/{clusterName}/services/{serviceName}/metrics

Fetch metric readings for a particular service.

By default, this call will look up all metrics available for the service. If only specific metrics are desired, use the metrics parameter.

By default, the returned results correspond to a 5 minute window based on the provided end time (which defaults to the current server time). The from and to parameters can be used to control the window being queried. A maximum window of 3 hours is enforced.

When requesting a "full" view, aside from the extended properties of the returned metric data, the collection will also contain information about all metrics available for the service, even if no readings are available in the requested window.

HDFS services that have more than one nameservice will not expose any metrics. Instead, the nameservices should be queried separately.

GET /clusters/{clusterName}/services/{serviceName}/roleTypes

List the supported role types for a service.

DELETE /clusters/{clusterName}/services/{serviceName}/tags

Remove the tags associated with the service. Tag names beginning with the prefix _cldr_ (case insensitive) are reserved for internal use by Cloudera.

GET /clusters/{clusterName}/services/{serviceName}/tags

Returns the tags associated with this service. Tag names beginning with the prefix _cldr_ (case insensitive) are reserved for internal use by Cloudera.

PUT /clusters/{clusterName}/services/{serviceName}/tags

Attach tags to the service. Tag names beginning with the prefix _cldr_ (case insensitive) are reserved for internal use by Cloudera.

GET /clusters/{clusterName}/services/{serviceName}/yarnUtilization

Provides the resource utilization of the yarn service as well as the resource utilization per tenant. Only available with Cloudera Manager Enterprise Edition.

POST /clusters/{clusterName}/services/{serviceName}/commands/copyHdfsFile

Copies source HDFS file to destination cluster HDFS

POST /clusters/{clusterName}/services/{serviceName}/commands/createHdfsFile

POST /clusters/{clusterName}/services/{serviceName}/commands/createOozieDb

Creates the Oozie Database Schema in the configured database. This command does not create database. This command creates only tables required by Oozie. To create database, please refer to oozieCreateEmbeddedDatabase()

Available since API v2.

POST /clusters/{clusterName}/services/{serviceName}/commands/createSolrHdfsHomeDir

Creates the home directory of a Solr service in HDFS.

Available since API v4.

POST /clusters/{clusterName}/services/{serviceName}/commands/createSqoopUserDir

Creates the user directory of a Sqoop service in HDFS.

Available since API v4.

POST /clusters/{clusterName}/services/{serviceName}/commands/decommission

Decommission roles of a service.

For HBase services, the list should contain names of RegionServers to decommission.

For HDFS services, the list should contain names of DataNodes to decommission.

DELETE /clusters/{clusterName}/services/{serviceName}/commands/deleteHdfsPath

Deletes the file or directory, specified by the given path, on the given HDFS service.

POST /clusters/{clusterName}/services/{serviceName}/commands/deployClientConfig

Deploy a service's client configuration.

The client configuration is deployed to the hosts where the given roles are running.

Added in v3: passing null for the role name list will deploy client configs to all known service roles. Added in v6: passing an empty role name list will deploy client configs to all known service roles.

In Cloudera Manager 5.3 and newer, client configurations are fully managed, meaning that the server maintains state about which client configurations should exist and be managed by alternatives, and the agents actively rectify their hosts with this state. Consequently, if this API call is made with a specific set of roles, Cloudera Manager will deactivate, from alternatives, any deployed client configs from any non-gateway roles that are not specified as arguments. Gateway roles are always preserved, and calling this API with an empty or null argument continues to deploy to all roles.

POST /clusters/{clusterName}/services/{serviceName}/commands/disableJtHa

Disable high availability (HA) for JobTracker. As part of disabling HA, any services that depend on the MapReduce service being modified will be stopped. The command arguments provide options to specify name of JobTracker that will be preserved. The Command will redeploy the client configurations for services of the cluster after HA has been disabled.

POST /clusters/{clusterName}/services/{serviceName}/commands/disableRmHa

Disable high availability (HA) for ResourceManager. As part of disabling HA, any services that depend on the YARN service being modified will be stopped. The command arguments provide options to specify name of ResourceManager that will be preserved. The command will redeploy the client configurations for services of the cluster after HA has been disabled.

POST /clusters/{clusterName}/services/{serviceName}/commands/disableSentryHa

Disable high availability (HA) for Sentry service.

This command only applies to CDH 5.13+ Sentry services.

The command will keep exactly one Sentry server, on the specified host, and update the ZooKeeper configs needed for Sentry.

All services that depend on HDFS will be restarted after enabling Sentry HA.

Note: Sentry doesn't support Rolling Restart.

POST /clusters/{clusterName}/services/{serviceName}/commands/enableJtHa

Enable high availability (HA) for a JobTracker.

This command only applies to CDH4 MapReduce services.

The command will create a new JobTracker on the specified host and then create an active/standby pair with the existing JobTracker. Autofailover will be enabled using ZooKeeper. A ZNode will be created for this purpose. Command arguments provide option to forcefully create this ZNode if one already exists. A node may already exists if JobTracker was previously enabled in HA mode but HA mode was disabled later on. The ZNode is not deleted when HA is disabled.

As part of enabling HA, any services that depends on the MapReduce service being modified will be stopped. Command will redeploy the client configurations for services of the cluster after HA has been enabled.

POST /clusters/{clusterName}/services/{serviceName}/commands/enableRmHa

Enable high availability (HA) for a YARN ResourceManager.

This command only applies to CDH5+ YARN services.

The command will create a new ResourceManager on the specified host and then create an active/standby pair with the existing ResourceManager. Autofailover will be enabled using ZooKeeper.

As part of enabling HA, any services that depends on the YARN service being modified will be stopped. Command will redeploy the client configurations for services of the cluster after HA has been enabled.

POST /clusters/{clusterName}/services/{serviceName}/commands/enableSentryHa

Enable high availability (HA) for Sentry service.

This command only applies to CDH 5.13+ Sentry services.

The command will create a new Sentry server on the specified host and set the ZooKeeper configs needed for Sentry HA.

As part of enabling HA, all services that depend on HDFS will be restarted after enabling Sentry HA.

Note: Sentry doesn't support Rolling Restart.

POST /clusters/{clusterName}/services/{serviceName}/commands/enterMaintenanceMode

Put the service into maintenance mode. This is a synchronous command. The result is known immediately upon return.

Available since API v2.

POST /clusters/{clusterName}/services/{serviceName}/commands/exitMaintenanceMode

Take the service out of maintenance mode. This is a synchronous command. The result is known immediately upon return.

Available since API v2.

POST /clusters/{clusterName}/services/{serviceName}/commands/exportSentryPermissions

Export Sentry Permissions.

POST /clusters/{clusterName}/services/{serviceName}/commands/firstRun

Prepare and start a service.

Perform all the steps needed to prepare the service and start it.

Available since API v7.

GET /clusters/{clusterName}/services/{serviceName}/commands/getServicesFromRanger

Collects information about the services defined in the local Ranger service.

Optionally if sourcePeer, sourceCluster, sourceService are provided, then it will call the same API endpoint on that given source CM peer, and merges the result of the local (ApiRangerServiceList#getServices()) and remote (ApiRangerServiceList#getRemoteServices()) Ranger services.

POST /clusters/{clusterName}/services/{serviceName}/commands/hbaseCreateRoot

Creates the root directory of an HBase service.

POST /clusters/{clusterName}/services/{serviceName}/commands/hbaseCreateUserDirectory

Create the HBase user directory (usually /user/hbase).

POST /clusters/{clusterName}/services/{serviceName}/commands/hbaseReplicationFirstTimeSetupAutomatic

Starts an automatic HBase replication first time setup. After doing some configuration (see #hbaseReplicationSetup(String, boolean, ApiHBaseReplicationSetupCommandArgs)), it restarts both the source and target clusters.

POST /clusters/{clusterName}/services/{serviceName}/commands/hbaseReplicationFirstTimeSetupCleanAndReset

Cleans and resets the HBase replication first time setup on the given source and target:

• clears the HBase replication auxiliary info and deletes the JCEKS files
• Optionally restarts HBase services
• Resets the HBase replication first time setup status

POST /clusters/{clusterName}/services/{serviceName}/commands/hbaseReplicationFirstTimeSetupForceReady

Force sets the HBase replication first time setup status to be READY for the given source and target. Note that after this operation, the pending HBase replication policies, which have the waitForHBaseReplicationSetup flag set to true, will NOT be completed.

POST /clusters/{clusterName}/services/{serviceName}/commands/hbaseReplicationFirstTimeSetupManual

Starts a manual HBase replication first time setup. After doing some configuration (see #hbaseReplicationSetup(String, boolean, ApiHBaseReplicationSetupCommandArgs)), it restarts the target cluster only. Source cluster has to be restarted manually, after which the #hbaseReplicationFirstTimeSetupManualContinue(String, ApiServiceRef) API endpoint should be called to finish the HBase replication first time setup.

POST /clusters/{clusterName}/services/{serviceName}/commands/hbaseReplicationFirstTimeSetupManualContinue

Should be called after #hbaseReplicationFirstTimeSetupManual(String, ApiHBaseReplicationSetupCommandArgs) to finish the manual HBase replication first time setup.

POST /clusters/{clusterName}/services/{serviceName}/commands/hbaseReplicationFirstTimeSetupReset

Resets/removes the HBase replication first time setup status for the given source and target.

GET /clusters/{clusterName}/services/{serviceName}/commands/hbaseReplicationFirstTimeSetupStatus

POST /clusters/{clusterName}/services/{serviceName}/commands/hbaseReplicationSetup

Perform one time setup for HBase replication. Generate the a keystore to HDFS for use by replication and transfer the keystore to HDFS on the the peer.

POST /clusters/{clusterName}/services/{serviceName}/commands/hbaseReplicationSetupAdmin

POST /clusters/{clusterName}/services/{serviceName}/commands/hbaseShellCommand

Execute a hbase shell command

POST /clusters/{clusterName}/services/{serviceName}/commands/hbaseUpgrade

Upgrade HBase data in HDFS and ZooKeeper as part of upgrade from CDH4 to CDH5.

This is required in order to run HBase after upgrade.

Available since API v6.

POST /clusters/{clusterName}/services/{serviceName}/commands/hdfsAddSBNNToNS

POST /clusters/{clusterName}/services/{serviceName}/commands/hdfsCreateTmpDir

Creates a tmp directory on the HDFS filesystem.

Available since API v2.

POST /clusters/{clusterName}/services/{serviceName}/commands/hdfsDisableAutoFailover

Disable auto-failover for a highly available HDFS nameservice.

The command will modify the nameservice's NameNodes configuration to disable automatic failover, and delete the existing failover controllers.

The ZooKeeper dependency of the service will not be removed.

POST /clusters/{clusterName}/services/{serviceName}/commands/hdfsDisableHa

Disable high availability (HA) for an HDFS NameNode.

The NameNode to be kept must be running before HA can be disabled.

As part of disabling HA, any services that depend on the HDFS service being modified will be stopped. The command arguments provide options to re-start these services and to re-deploy the client configurations for services of the cluster after HA has been disabled.

POST /clusters/{clusterName}/services/{serviceName}/commands/hdfsDisableNnHa

Disable High Availability (HA) with Automatic Failover for an HDFS NameNode.

As part of disabling HA, any services that depend on the HDFS service being modified will be stopped. The command will delete the Standby NameNode associated with the specified NameNode. Any FailoverControllers associated with the NameNode's nameservice are also deleted. A SecondaryNameNode is created on the host specified by the arugments.

If no nameservices uses Quorum Journal after HA is disabled for the specified nameservice, then all JournalNodes are also deleted.

Then, HDFS service is restarted and all services that were stopped are started again afterwards. Finally, client configs for HDFS and its depedents will be re-deployed.

POST /clusters/{clusterName}/services/{serviceName}/commands/hdfsEnableAutoFailover

Enable auto-failover for an HDFS nameservice.

This command requires that the nameservice exists, and HA has been configured for that nameservice.

The command will create the needed failover controllers, perform the needed initialization and configuration, and will start the new roles. The existing NameNodes which are part of the nameservice will be re-started in the process.

This process may require changing the service's configuration, to add a dependency on the provided ZooKeeper service. This will be done if such a dependency has not been configured yet, and will cause roles that are not affected by this command to show an "outdated configuration" status.

If a ZooKeeper dependency has already been set up by some other means, it does not need to be provided in the command arguments.

POST /clusters/{clusterName}/services/{serviceName}/commands/hdfsEnableHa

Enable high availability (HA) for an HDFS NameNode.

The command will set up the given "active" and "stand-by" NameNodes as an HA pair. Both nodes need to already exist.

If there is a SecondaryNameNode associated with either given NameNode instance, it will be deleted.

Note that while the shared edits path may be different for both nodes, they need to point to the same underlying storage (e.g., an NFS share).

As part of enabling HA, any services that depend on the HDFS service being modified will be stopped. The command arguments provide options to re-start these services and to re-deploy the client configurations for services of the cluster after HA has been enabled.

POST /clusters/{clusterName}/services/{serviceName}/commands/hdfsEnableNnHa

Enable High Availability (HA) with Automatic Failover for an HDFS NameNode.

The command will create a Standby NameNode for the given nameservice and create FailoverControllers for both Active and Standby NameNodes. The SecondaryNameNode associated with the Active NameNode will be deleted.

The command will also create JournalNodes needed for HDFS HA if they do not already exist.

As part of enabling HA, any services that depend on the HDFS service being modified will be stopped. They will be restarted after HA has been enabled. Finally, client configs for HDFS and its depedents will be re-deployed.

POST /clusters/{clusterName}/services/{serviceName}/commands/hdfsFailover

Initiate a failover in an HDFS HA NameNode pair.

The arguments should contain the names of the two NameNodes in the HA pair. The first one should be the currently active NameNode, the second one the NameNode to be made active.

POST /clusters/{clusterName}/services/{serviceName}/commands/hdfsFinalizeRollingUpgrade

Finalizes the rolling upgrade for HDFS by updating the NameNode metadata permanently to the next version. Should be done after doing a rolling upgrade to a CDH version >= 5.2.0.

Available since API v8.

POST /clusters/{clusterName}/services/{serviceName}/commands/hdfsRollEdits

Roll the edits of an HDFS NameNode or Nameservice.

Available since API v3.

POST /clusters/{clusterName}/services/{serviceName}/commands/hdfsUpgradeMetadata

Upgrade HDFS Metadata as part of a major version upgrade.

When doing a major version upgrade for HDFS, it is necessary to start HDFS in a special mode where it will do any necessary upgrades of stored metadata. Trying to start HDFS normally will result in an error message and the NameNode(s) failing to start.

The metadata upgrade must eventually be finalized, using the hdfsFinalizeMetadataUpgrade command on the NameNode.

Available since API v6.

POST /clusters/{clusterName}/services/{serviceName}/commands/hiveCreateHiveUserDir

Create the Hive user directory

Available since API v4.

POST /clusters/{clusterName}/services/{serviceName}/commands/hiveCreateHiveWarehouse

Create the Hive warehouse directory, on Hive services.

Available since API v3.

POST /clusters/{clusterName}/services/{serviceName}/commands/hiveCreateHiveWarehouseExternal

Create the Hive warehouse external directory for Private Cloud.

POST /clusters/{clusterName}/services/{serviceName}/commands/hiveCreateMetastoreDatabase

Create the Hive Metastore Database. Only works with embedded postgresql database.

This command is to be run whenever a new user and database needs to be created in the embedded postgresql database for a Hive service. This command should usually be followed by a call to hiveCreateMetastoreDatabaseTables.

Available since API v4.

POST /clusters/{clusterName}/services/{serviceName}/commands/hiveCreateMetastoreDatabaseTables

Create the Hive Metastore Database tables.

This command is to be run whenever a new database has been specified. Will do nothing if tables already exist. Will not perform an upgrade. Only Available when all Hive Metastore Servers are stopped.

Available since API v3.

POST /clusters/{clusterName}/services/{serviceName}/commands/hiveUpdateMetastoreNamenodes

Update Hive Metastore to point to a NameNode's Nameservice name instead of hostname.

Back up the Hive Metastore Database before running this command.

This command is to be run after enabling HDFS High Availability. Only available when all Hive Metastore Servers are stopped.

Available since API v4.

POST /clusters/{clusterName}/services/{serviceName}/commands/hiveUpgradeMetastore

Upgrade Hive Metastore as part of a major version upgrade.

When doing a major version upgrade for Hive, it is necessary to upgrade data in the metastore database.

Available since API v6.

POST /clusters/{clusterName}/services/{serviceName}/commands/hiveValidateMetastoreSchema

Validate the Hive Metastore Schema.

This command checks the Hive metastore schema for any errors and corruptions. This command is to be run on two instances:

POST /clusters/{clusterName}/services/{serviceName}/commands/hueCreateHiveWarehouse

Create the Beeswax role's Hive warehouse directory, on Hue services.

POST /clusters/{clusterName}/services/{serviceName}/commands/hueDumpDb

Runs Hue's dumpdata command. Available since API v10.

POST /clusters/{clusterName}/services/{serviceName}/commands/hueLoadDb

Runs Hue's loaddata command. Available since API v10.

POST /clusters/{clusterName}/services/{serviceName}/commands/hueSyncDb

Runs Hue's syncdb command. Available since API v10.

POST /clusters/{clusterName}/services/{serviceName}/commands/impalaCreateCatalogDatabase

Not needed in CM 5.0.0 Release, since Impala Catalog Database is not yet available in CDH as of this release. Create the Impala Catalog Database. Only works with embedded postgresql database.

This command is to be run whenever a new user and database needs to be created in the embedded postgresql database for the Impala Catalog Server. This command should usually be followed by a call to impalaCreateCatalogDatabaseTables.

Available since API v6.

POST /clusters/{clusterName}/services/{serviceName}/commands/impalaCreateCatalogDatabaseTables

Not needed in CM 5.0.0 Release, since Impala Catalog Database is not yet available in CDH as of this release. Create the Impala Catalog Database tables.

This command is to be run whenever a new database has been specified. Will do nothing if tables already exist. Will not perform an upgrade. Only available when all Impala Catalog Servers are stopped.

Available since API v6.

POST /clusters/{clusterName}/services/{serviceName}/commands/impalaCreateUserDir

Create the Impala user directory

Available since API v6.

POST /clusters/{clusterName}/services/{serviceName}/commands/impalaDisableLlamaHa

Not Supported. Llama was removed.

POST /clusters/{clusterName}/services/{serviceName}/commands/impalaDisableLlamaRm

Not Supported. Llama was removed.

POST /clusters/{clusterName}/services/{serviceName}/commands/impalaEnableLlamaHa

Not Supported. Llama was removed.

POST /clusters/{clusterName}/services/{serviceName}/commands/impalaEnableLlamaRm

Not Supported. Llama was removed.

POST /clusters/{clusterName}/services/{serviceName}/commands/importMrConfigsIntoYarn

Import MapReduce configuration into Yarn, overwriting Yarn configuration.

You will lose existing Yarn configuration. Read all MapReduce configuration, role assignments, and role configuration groups and update Yarn with corresponding values. MR1 configuration will be converted into the equivalent MR2 configuration.

Before running this command, Yarn must be stopped and MapReduce must exist with valid configuration.

Available since API v6.

POST /clusters/{clusterName}/services/{serviceName}/commands/initSolr

Initializes the Solr service in Zookeeper.

Available since API v4.

POST /clusters/{clusterName}/services/{serviceName}/commands/installMrFrameworkJars

Creates an HDFS directory to hold the MapReduce2 framework JARs (if necessary), and uploads the framework JARs to it.

This command is run automatically when starting a YARN service for the first time, or when upgrading an existing YARN service. It can also be run manually to ensure that the latest version of the framework JARS is installed.

Available since API v30.

POST /clusters/{clusterName}/services/{serviceName}/commands/installOozieShareLib

Creates directory for Oozie user in HDFS and installs the ShareLib in it.

This command should be re-run after a major version upgrade to refresh the ShareLib to the latest version.

Available since API v3.

POST /clusters/{clusterName}/services/{serviceName}/commands/migrateToSentry

Migrates the HBase Indexer policy-based permissions to Sentry, by invoking the SentryConfigToolIndexer.

Note:

POST /clusters/{clusterName}/services/{serviceName}/commands/offline

Offline roles of a service.

Currently the offline operation is only supported by HDFS.

For HDFS, the offline operation will put DataNodes into HDFS IN MAINTENANCE state which prevents unnecessary re-replication which could occur if decommissioned.

The timeout parameter is used to specify a timeout for offline. For HDFS, when the timeout expires, the DataNode will automatically transition out of HDFS IN MAINTENANCE state, back to HDFS IN SERVICE state.

POST /clusters/{clusterName}/services/{serviceName}/commands/oozieCreateEmbeddedDatabase

Create the Oozie Server Database. Only works with embedded postgresql database.

This command is to be run whenever a new user and database need to be created in the embedded postgresql database for an Oozie service. This command should usually be followed by a call to createOozieDb.

Available since API v10.

POST /clusters/{clusterName}/services/{serviceName}/commands/oozieDisableHa

Disable high availability (HA) for Oozie. As part of disabling HA, any services that depend on the Oozie service being modified will be stopped. The command arguments provide options to specify name of Oozie Server that will be preserved. After deleting, other Oozie servers, all the services that were stopped are restarted.

POST /clusters/{clusterName}/services/{serviceName}/commands/oozieDumpDatabase

Dump the Oozie Server Database.

POST /clusters/{clusterName}/services/{serviceName}/commands/oozieEnableHa

Enable high availability (HA) for Oozie service.

This command only applies to CDH5+ Oozie services.

The command will create new Oozie Servers on the specified hosts and set the ZooKeeper and Load Balancer configs needed for Oozie HA.

As part of enabling HA, any services that depends on the Oozie service being modified will be stopped and restarted after enabling Oozie HA.

POST /clusters/{clusterName}/services/{serviceName}/commands/oozieLoadDatabase

Load the Oozie Server Database from dump.

POST /clusters/{clusterName}/services/{serviceName}/commands/oozieUpgradeDb

Upgrade Oozie Database schema as part of a major version upgrade.

When doing a major version upgrade for Oozie, it is necessary to upgrade the schema of its database before Oozie can run successfully.

Available since API v6.

POST /clusters/{clusterName}/services/{serviceName}/commands/recommission

Recommission roles of a service.

The list should contain names of slave roles to recommission.

Available since API v2.

POST /clusters/{clusterName}/services/{serviceName}/commands/recommissionWithStart

Start and recommission roles of a service.

The list should contain names of slave roles to start and recommission.

Warning: Evolving. This method may change in the future and does not offer standard compatibility guarantees. Only support by HDFS. Do not use without guidance from Cloudera.

Available since API v15.

POST /clusters/{clusterName}/services/{serviceName}/commands/restart

Restart the service.

POST /clusters/{clusterName}/services/{serviceName}/commands/rollingRestart

Command to run rolling restart of roles in a service. The sequence is:

1. Restart all the non-slave roles
2. If slaves are present restart them in batches of size specified in RollingRestartCmdArgs
3. Perform any post-command needed after rolling restart

Available since API v3. Only available with Cloudera Manager Enterprise Edition.

POST /clusters/{clusterName}/services/{serviceName}/commands/sentryCreateDatabase

Create the Sentry Server Database. Only works with embedded postgresql database.

This command is to be run whenever a new user and database need to be created in the embedded postgresql database for a Sentry service. This command should usually be followed by a call to sentryCreateDatabaseTables.

Available since API v7.

POST /clusters/{clusterName}/services/{serviceName}/commands/sentryCreateDatabaseTables

Create the Sentry Server Database tables.

This command is to be run whenever a new database has been specified. Will do nothing if tables already exist. Will not perform an upgrade. Only Available when Sentry Server is stopped.

Available since API v7.

POST /clusters/{clusterName}/services/{serviceName}/commands/sentryUpgradeDatabaseTables

Upgrade the Sentry Server Database tables.

This command is to be run whenever Sentry requires an upgrade to its database tables.

Available since API v8.

POST /clusters/{clusterName}/services/{serviceName}/commands/solrBootstrapCollections

Bootstraps Solr Collections after the CDH upgrade.

Note: This is only needed for upgrading to CDH6.0.

Available since API v30.

POST /clusters/{clusterName}/services/{serviceName}/commands/solrBootstrapConfig

Bootstraps Solr config during the CDH upgrade.

Note: This is only needed for upgrading to CDH6.0.

Available since API v30.

POST /clusters/{clusterName}/services/{serviceName}/commands/solrConfigBackup

Backs up Solr configuration metadata before CDH upgrade.

Note:

POST /clusters/{clusterName}/services/{serviceName}/commands/solrMigrateSentryPrivilegesCommand

Migrates Sentry privileges to new model compatible to support more granular permissions if Solr is configured with a Sentry service.

Note:

POST /clusters/{clusterName}/services/{serviceName}/commands/solrReinitializeStateForUpgrade

Reinitializes the Solr state by clearing the Solr HDFS data directory, the Solr data directory, and the Zookeeper state.

Note:

POST /clusters/{clusterName}/services/{serviceName}/commands/solrValidateMetadata

Validates Solr metadata and configurations.

Note: This is only needed for upgrading to CDH6.0.

Available since API v30.

POST /clusters/{clusterName}/services/{serviceName}/commands/sqoopCreateDatabaseTables

Create the Sqoop2 Server Database tables.

This command is to be run whenever a new database has been specified. Will do nothing if tables already exist. Will not perform an upgrade. Only available when Sqoop2 Server is stopped.

Available since API v10.

POST /clusters/{clusterName}/services/{serviceName}/commands/sqoopUpgradeDb

Upgrade Sqoop Database schema as part of a major version upgrade.

When doing a major version upgrade for Sqoop, it is necessary to upgrade the schema of its database before Sqoop can run successfully.

Available since API v6.

POST /clusters/{clusterName}/services/{serviceName}/commands/start

Start the service.

POST /clusters/{clusterName}/services/{serviceName}/commands/stop

Stop the service.

POST /clusters/{clusterName}/services/{serviceName}/commands/switchToMr2

Change the cluster to use MR2 instead of MR1. Services will be restarted.

Will perform the following steps:

• Update all services that depend on MapReduce to instead depend on Yarn.
• Stop MapReduce
• Start Yarn (MR2 Included)
• Deploy Yarn (MR2) Client Configuration

Available since API v6.

POST /clusters/{clusterName}/services/{serviceName}/commands/yarnApplicationDiagnosticsCollection

Collect the Diagnostics data for Yarn applications

Available since API v8.

POST /clusters/{clusterName}/services/{serviceName}/commands/yarnCreateCmContainerUsageInputDirCommand

Creates the HDFS directory where YARN container usage metrics are stored by NodeManagers for CM to read and aggregate into app usage metrics.

Available since API v13.

POST /clusters/{clusterName}/services/{serviceName}/commands/yarnCreateJobHistoryDirCommand

Create the Yarn job history directory

Available since API v6.

POST /clusters/{clusterName}/services/{serviceName}/commands/yarnFormatStateStore

Formats the state store in ZooKeeper used for Resource Manager High Availability. Typically used while moving from non-secure to secure cluster or vice-versa.

Available since API v8.

POST /clusters/{clusterName}/services/{serviceName}/commands/yarnNodeManagerRemoteAppLogDirCommand

Create the Yarn NodeManager remote application log directory

Available since API v6.

POST /clusters/{clusterName}/services/{serviceName}/commands/zooKeeperCleanup

Clean up all running server instances of a ZooKeeper service.

This command removes snapshots and transaction log files kept by ZooKeeper for backup purposes. Refer to the ZooKeeper documentation for more details.

POST /clusters/{clusterName}/services/{serviceName}/commands/zooKeeperInit

Initializes all the server instances of a ZooKeeper service.

ZooKeeper server roles need to be initialized before they can be used.

POST /clusters/{clusterName}/services/{serviceName}/commands/{commandName}

Executes a command on the service specified by name.

Available since API v6.

GET /clusters/{clusterName}/services/{serviceName}/reports/hdfsUsageReport

Fetch the HDFS usage report. For the requested time range, at the specified aggregation intervals, the report shows HDFS disk usages per user.

This call supports returning JSON or CSV, as determined by the "Accept" header of application/json or text/csv.

Available since API v4. Only available with Cloudera Manager Enterprise Edition.

GET /clusters/{clusterName}/services/{serviceName}/reports/mrUsageReport

Fetch the MR usage report. For the requested time range, at the specified aggregation intervals, the report shows job CPU usages (and other metrics) per user.

This call supports returning JSON or CSV, as determined by the "Accept" header of application/json or text/csv.

Available since API v4. Only available with Cloudera Manager Enterprise Edition.