Known Issues Fixed in Cloudera Manager 4.1.2
— The default retention period for Activities data has been changed to 14 days from 90 days.
The default retention period for Activity Monitor data has been reduced from 90 days to 14 days. Data older than 14 days will be purged. A side effect of this is that after an upgrade, if you have not changed the default retention period, the first time the Activity Monitor is started it will purge all retained data older than 14 days — if this is a large amount of data this can take a significant amount of time. If you changed the retention period setting prior to upgrade, your setting is maintained and you will not see this problem. If you want to retain more than 14 days of activities data after the upgrade, you can change the default setting prior to the upgrade, and your setting will be maintained.
Severity: Low
Resolution: Fixed in Cloudera Manager 4.1.2.
Workaround: You can change the Activities retention period by changing the Purge Activities Data at This Age property, found under the Configuration tab, Activity Monitor category of the Cloudera Management service.
— Setting up a cluster and applying a license using the API gives "Outdated Configuration" warnings after restarting the Cloudera Manager server.
If a Cloudera Manager 4.x cluster was set up using the API, restarting the Cloudera Manager server results in "Started with Outdated Configuration" warnings for all roles of all services. The warning is innocuous and can be removed by restarting all the services. This happens even after upgrading the cluster to CM 4.1.2 if the cluster was set up with an earlier version of Cloudera Manager. To fix this problem permanently you can start and then exit the express wizard, as described below.
Severity: Low
Resolution: Fixed in Cloudera Manager 4.1.2.
Workaround: Restarting services will update the Status of the services. To fix the problem permanently, point your browser to the wizard welcome page: https://<server>:<port>/cmf/express-wizard/welcome Then exit the wizard immediately. This will cause the erroneous status to be reset.
— After adding and then removing the YARN service, MapReduce jobs no longer run.
After adding YARN as a service, MapReduce jobs run successfully. However, after removing the YARN service, MapReduce jobs fail even if there is a MapReduce v1 service in the cluster. This is because the MapReduce jobs are still trying to use the YARN service. The alternatives configuration is still pointing to YARN as the execution environment, but it is no longer possible to change its "Alternatives Priority" property as the service no longer exists.
Severity: Med
Resolution: Fixed in Cloudera Manager 4.1.2. Now, when adding the YARN service, you will need to raise the YARN service's priority or MapReduce jobs will continue to run under MapReduce v1.
Workaround: In the Cloudera Manager Admin Console, go the MapReduce service's Configuration tab, search for "alternatives" and raise the priority of the MapReduce Service.