Hi Miles,   Thanks for your message. The username password field are optional, users can set a value if their mail server requires authentication.  Can you describe what is the actual error when the values are not set, if possible can you provide your troubleshooting steps that suggested that these fields are required any errors in Alert Publisher or sendmail logs.  ... View more

Indeed, you do appear to have version CM 5.7.0.   Would you mind posting a screenshot of the page that showing the error, the list of available parcels on your CM from the parcels url - http://CM-SERVER:7180/api/v12/clusters/REPLACE_WITH_CLUSTER_NAME/parcels - http://CM-SERVER:7180/api/v12/clusters/REPLACE_WITH_CLUSTER_NAME/parcels/usage and finally yourREMOTE_PARCEL_REPO_URLS from the following url - http://CM-SERVER:7180/api/v12/cm/config Thank you ... View more

Can you let me know your Cloudera Manager version, this should be in the CM Web UI in the top-right menu Support> About   > By the way, why the url "http://archive.cloudera.com/cdh5/parcels/latest/" targeting to 5.3.    To simplify this transition away from a /latest symlink mechanism, CM 5.4 and higher make use of a Remote Parcel Repository URL configuration variable that lets the Cloudera Manager Server negotiate and determine the Highest-Supported CDH version using this {latest_supported} variable. If you upgrade to Cloudera Manager 5.4.0 or higher and wish to see all supported CDH parcel versions, ensure your parcel settings for Report Parcel Repository URLs contains a property similar to the following (assuming your cluster can contact archive.cloudera.com😞 http://archive.cloudera.com/cdh5/parcels/{latest_supported}   reference: https://community.cloudera.com/t5/Cloudera-Manager-Installation/Why-is-CDH-5-4-not-set-as-the-latest-parcels-at-http-archive/td-p/26962 ... View more

To iterate what you've run; # Remove Cloudera yum repo < see [1] how to install this rm -vRf /etc/yum.repos.d/cloudera* /etc/cloudera-* # remove Cloudera shared libraries, and all the cloudera yum cached packages files # /var/lib/cloudera-scm-agent also contains the UUID [3] - so you might have also cleared this. # what this effectively mean that once you re-install the agents packages the aget/host will not be associated with any clusters. # we could fix this but you'll need you uuid from the database. rm -vRf /usr/share/cmf /var/lib/cloudera* /var/cache/yum/cloudera* # remove Cloudera logs rm -vRf /var/log/cloudera-* # Remove cloudera yum/rpm packages yum remove cloudera* # clean up various things which accumulate in the yum cache directory over time. More complete details can be found in the Clean Options section below. yum clean all   > But I was trying to upgrade cloudera manager iteself. Unfortunetly after that I failed to install/upgrde cloudera agent in nodes. Did you fail to upgrade Cloudera Manager Server and Agents?  What version of Cloudera Manager you are looking to upgrade to? What is the value for your 'com.cloudera.cmf.db.type' in the /etc/cloudera-scm-server/db.properties file.   From the supplied information, you can still re-install Cloudera Manager following the installation instructions [1], and since you're behind proxy you could download [2] the .rpms and install them manually.       [1] http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_install_path_b.html [2] ie: RedHat 6 variant CM packages - http://archive.cloudera.com/cm5/redhat/6/x86_64/cm/5/RPMS/x86_64/ [3] Directory that store Cloudera Manager Agent state that persists across instances of the agent process and system reboots. The agent's UUID is stored here. Default: /var/lib/cloudera-scm-agent.   ... View more

would you be able to list your 'serviceDependencies', there's a know issue that we've identified with SPARK/CSD - just wanted to confirm if you're running into the same. ... View more