Hello Saikiran,   This normally means there is insufficient disk space in the parcel distribution location. By default this is in /opt/cloudera (/opt/cloudera/parcel-cache/ and /opt/cloudera/parcels/ specifically). Please ensure you have roughly 2-2.5x the size of the parcel available free in that path so the parcel can be distributed, then untar'd and set into place.   There is a Knowledgebase article that discusses this error message as well (with the same detail as above), which I'll link shortly.   Regards, -- Mark Schnegelberger ... View more

Nice catch.   For reference this is documented in the Known Issues / Release notes:   ========= AWS Installation wizard requires Java 7u45 to be installed on Cloudera Manager Server host Cloudera Manager 5.1 installs Java 7u55 by default. However, the AWS installation wizard does not work with Java 7u55 due to a bug in the jClouds version packaged with Cloudera Manager. Workaround: Stop the Cloudera Manager Server. $ sudo service cloudera-scm-server stop Uninstall Java 7u55 from the Cloudera Manager Server host. Install Java 7u45 (which you can download from http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase7-521261.html#jdk-7u45-oth-JPR) on the Cloudera Manager Server host. Start the Cloudera Manager Server. $ sudo service cloudera-scm-server start Run the AWS installation wizard. =========   Regards, -- ... View more

Hi Greg,   You found the correct way to do things, so you're already well on the way! Let's get your configuration overrides removed so th global can take precedence.   Cloudera Manager will be aware that you have host-level overrides and in fact provides a way to help you batch them back to default such that they inherit this from the global setting. Here are a few screenshots of how that would look:   Go to the Hosts tab, then Configuration tab. Click Monitoring on the left side and find the Cloudera Manager Agent Parcel Directory Free Space Monitoring setting you've changed. There should be grey text "Overridden by N host(s)". Expand this, then click Edit Overrides. On the overrides screen you can click the top-most checkbox to select ALL hosts for which you individually applied overrides, and tell them to revert back to inheriting their configuration from the global level: Now return to the Hosts tab, then Configuration tab. Click Monitoring on the left side and find the Cloudera Manager Agent Parcel Directory Free Space Monitoring configuration property. You'll find that in the property coulmn for this, there is no mention of overrides. All hosts are now using this global setting. Congratulations! Repeat for 'Cloudera Manager Agent Parcel Directory Free Space Monitoring Percentage Thresholds' or others as necessary.   Hope this helps, -- Mark S. ... View more

Hi ranks, In Cloudera Manager 5 and higher, every chart you see in the web UI will provide you a direct /timeseries URL showing exactly how that chart itself retrieved metrics with the /timeseries endpoint! You can grab this same URL and use it with curl.   Find any chart and click on the blue arrow that will appear at the top-right. Choose "Export JSON". This will open a new window with the location bar already populated. This URL is a fully-formatted /timeseries API endpoint! Feel free to use any of them as a springboard for your curl testing. I tried to post one here but the forum doesn't like the URL and won't let me post. However it'd look like this:       I can use this now directly with my curl command ($curl -v -u $USER:$PASS '$URL') and I get json output as requested.   $ curl -v -u $USER:$PASS 'http://my.cluster.com:7180/api/v6/timeseries?query=select+cpu_percent_across_hosts+where+category+%3D+CLUSTER+and+clusterId+%3D+%221%22&contentType=application%2Fjson&from=2014-07-17T14%3A31%3A57.948Z&to=2014-07-17T15%3A01%3A57.948Z'   Hope this helps! Add -v and/or -i to your curl testing to get more information about the 400 error you're getting, as needed. -- Mark S. ... View more

In the grand scheme, you should generally never, ever directly delete files on-disk that pertain to a database's data-files. It is advised to instead determine what application or process is writing to the database, and inserting that data. The appropriate place to address this is through the application that is writing them, not by deleting on-disk, or even by logging into postgres with psql and manually performing any activity.   In this case, I am fairly sure your Cloudera Manager deployment is using postgres running on port 7432, to house these databases: Cloudera Manager Activity Monitor Service Monitor Host Monitor Reports Manager   None of these should be manually altered by logging into the database.   This is relevant for Cloudera Manager 4.x only: Cause:  Cloudera Manager's Management Services use various databases to store their gathered data. These databases should be located where sufficient space is available to accommodate their growth. Without proper consideration, their default locations could be in a location with insufficient space and a volume could fill to 100%. Instructions The rate of growth for these databases is solely controlled via purge/expiration configuration in each of the services (Activity Monitor, Service Monitor, Host Monitor) individually. This controls how many hours/days worth of monitoring data are kept, and will directly then influence how large the databases will grow. Use these settings to apply bound to their growth: 1. Host Monitor:         * Host Monitor Data Expiration Period (hours) (default 168 hours, or 7 days) 2. Service Monitor:         * Service Monitor Data Expiration Period (hours) (default 168 hours, or 7 days) 3. Activity Monitor:         * Purge Activities Data at This Age (default 336 hours, or 14 days)         * Purge Attempts Data at This Age (default 336 hours, or 14 days)         * Purge MapReduce Service Data at This Age (default 336 hours, or 14 days) You can adjust these values downward, save them, and then in the background services will expire data older than the new value you set. For example, if you are using the cloudera-scm-server-db ("embedded postgres") database for Cloudera Manager, all these databases will consume space in the default path /var/lib/cloudera-scm-server-db/data. You may wish to halve the retention periods for all the above services so this location does not fill up. This is also discussed briefly under the header titled "Configuring Cloudera Management Services Database Limits" in our documentation:http://www.cloudera.com/content/cloudera-content/cloudera-docs/CM4Ent/4.5.4/Cloudera-Manager-Enterprise-Edition-User-Guide/cmeeug_topic_4_12.html     TL;DR: Please find and adjust the specific Cloudera Manager Management Services purging | expiration tunables that assist in controlling the size of the databases on-disk, or allocate more space to the partition where /var resides.     ... View more

Hello,   Sounds like you've had the CM5b1 installer or repo configuration present on this node before and have some lingering repo configuration. You may wish to: - rm -rf /var/cache/yum/x86_64/6/cloudera-manager/ - yum clean all   Also make sure in /etc/yum.repos.d that you don't have any conflicting repo files that would provide CM5b1 artifacts. What exact cloudera-manager-installer.bin file did you download (full URL)?     ... View more

Hello,   This page lists the supported operating systems for CDH5. There are no 32-bit OS's supported, you would need to use a 64-bit OS. This should explain the error you're seeing.   CDH4 does have some limited provision for 32-bit OS's as noted in its documentation, however the 32-bit limited provisions only pertain to RHEL/Cent/SL 6.2 and not 6.5 which you report that you are using.   Cloudera Manager 4 and Cloudera Manager 5 both require 64-bit OS's as well, as I believe you already noted.   Regards, -- ... View more