Hi, here is a summary of our blocking situation on our CDH Express 6.3.1 installation: - A crash happened on the storage where all the virtual nodes composing our Cluster insist - After solving the issue on the storage, our Cloudera cluster started again working, but with a critical error on HDFS Service Nodename - In fact, we have High Availability configured on 2 nodes, and exploring the situation we saw that Namenode 2 was active and Namenode 1 was DOWN - But the cluster worked - In an attempt to fix the issue, we tried several times to manually start the Namenode 1 from "HDFS --> Instances --> federation --> Namenode1 --> Start" but it was impossible to start manually - So, we decided to disable High Availability but the new configuration has not completed and actually is in pending status - It's in fact impossible to start HDFS service at all because an error pops up saying that "Nameservice nameservice1 has no SecondaryNameNode or High-Availability partner" It is interesting to note that (see attached picture) apparently we don't have High Availability configured anymore but cluster does not start anyhow As you can see from the second screenshot, if we try to manually start HDFS service a configuration issue is shown and it still believes to be running in High Availability mode and still looking for a "partner node" QUESTION: - Is there a way to force a NON-High-availability state and start the HDFS Service? Thank you for any advice and/or insights ... View more

Hello, a customer has a CDH Express 6.3.1 setup and: - It appears that suddenly one (and just one!) of the hosts listed in Hosts --> All Hosts is now showing as having a complete FQDN. It never used to have it (I have screenshots of previous configurations where ALL hosts in the list are shown with just the hostname and no domain) - Also, there are Stale Configurations waiting to be applied. If I click on them, they are related to a number of Client Configuration files waiting to be deployed, and sure enough ALL the lines in ALL the files are showing a single difference for that particular host! Now, I don't know what happened here. Nobody is reporting a CM configuration change made by them. I don't have History/Rollback capabilities on this cluster, as it's an Express Edition. Also, I have no Audits as well to check what (if any?) parameters have been recently changed I just know that Sysadmins recently performed a change in FQDN names on those hosts at OS level, because a monitoring tool (Zabbix) required it. But according to them nothing has been changed at CM Gui level My questions: - How can I manually check what (if any?) parameters have been recently changed in CM Gui? If I'd be able to identify a change/changes where the FQDN has been put in for that host, I could manually overwrite it - Or maybe the problem could be that CM "detected" a change at OS level (that config made by the sysadmins) and is now proposing a configuration change automatically? I really doubt it, but... Is it even a possibility? Thank you for any advice/help/support. Unfortunately I'm not directly managing that cluster so any requests for screenshots/checks on the system would receive slow replies... I have to ask the Customer. Knowing that, I eventually encourage to simply point out what configurations in CM can lead to change in single host FQDN changes being distributed in the cluster as client configurations ... View more

Hi, as we all know CDH 6.3.3 and subsequent versions are not available anymore under "Express licensing" model. Yet, I was in the process of setting up a 6.3.1 installation and apparently this is not possible, because a valid authentication (enterprise) is required. What am I doing wrong?   Below, a screenshot from the Installation Guide:     But when I try to import the 6.3.1 Repository (WITHOUT Username and Password as stated on the documentation itself for version < 6.3.3 I get the following error:           # rpm --import https://archive.cloudera.com/p/cm6/6.3.1/redhat7/yum/RPM-GPG-KEY-cloudera curl: (22) The requested URL returned error: 401 Authentication required errore: https://archive.cloudera.com/p/cm6/6.3.1/redhat7/yum/RPM-GPG-KEY-cloudera: lettura importazione fallita(2).           What am I doing wrong? @Cloudera1 Is this a mistake I'm committing or is it a problem with Cloudera implementing their policies in a wrong way?   Thanks for any insights   ... View more