If your system does not have pip, you can get it from your distro:
$ sudo apt-get install python-pip
## ... or use `yum install` if you are on CentOS
Alternatively, you can also install from source:
$ git clone git://github.com/cloudera/cm_api.git
$ cd cm_api/python
$ sudo python setup.py install
## ... the distribution egg file is in ./dist/
Once you have run one of the above commands, you can check to see
if the install succeeded by runningpip show cm-api.
Here is the last epydoc with older
python API client, for API version 19 (CM 5.14.0)
Each subsection continues from the previous one.
The ApiResource constructor takes other optional arguments, to specify
the API version, CM server port, HTTPS vs HTTP, etc.
Inspecting a Service
Now we have identified a CDH4 cluster. Find the HDFS service:
Inspect the HDFS service health and status:
Inspecting a Role
Find the NameNode and get basic info:
Similar to the service example, roles also expose their health checks.
First we look at what metrics are available:
Reading a metric. Suppose we are interested in the files_total and
dfs_capacity_used metrics, over the last 30 minutes.
This example uses the new-style /cm/timeseries endpoint (which uses
tsquery) to get metric data points.
Even though the example is querying HDFS metrics, the processing logic is the
same for all queries.
The old-style .../metrics endpoints (which exists under host, service
and role objects) are mostly useful for exploring what metrics are available.
Service Lifecycle and Commands
Restart HDFS. Start and stop work similarly:
You can also chain the wait() call:
Restart the NameNode. Commands on roles are issued at the service level,
and may be done in bulk.
Configuring Services and Roles
First, lets look at all possible service configs. For legacy reasons, this is a
2-tuple of service configs and an empty dictionary (as of API v3), so you have
to add “” below.
Now let’s change dfs_replication to 2. We use “dfs_replication” and not
dfs.replication” because we must match the keys of the config view. This is
also the same value as ApiConfig.name.
Configuring roles is done similarly. Normally you want to modify groups instead
of modifying each role one by one.
First, find the group(s).
See all possible role configuration. It’s the same for all groups of the same
role type in clusters with the same CDH version.
Let’s configure our data nodes to auto-restart.
To reset a config to default, pass in a value of None.
These examples cover how to get a new parcel up and running on
a cluster. Normally you would pick a specific parcel repository
and parcel version you want to install.
Add a CDH parcel repository. Note that in CDH 4, Impala and Solr are
in separate parcels. They are included in the CDH 5 parcel.
These examples requires v5 of the CM API or higher.
Download the parcel to the CM server.
Distribute the parcel so all agents on that cluster have a local copy of the parcel.
Activate the parcel so services pick up the new binaries upon next restart.
Restart your cluster to pick up the new parcel.
These examples cover how to export and import cluster template.
These examples requires v12 of the CM API or higher.
Import following modules
Export the cluster template as a json file
Make the required changes in the template file manually or using the python api’s. User needs to map the hosts in the target cluster with right host templates and provide information about all the variables,like database information in the target cluster.
Invoking import cluster template on the target cluster
User can use this command to track the progress. The progress can be tracked by command details page in UI
Project maintained by Cloudera,
and released under Apache License v2.
Contributions, bug reports and feature suggestions welcome.
Please post any questions to the
user mailing list
or the community forum.