Member since
11-14-2017
5
Posts
1
Kudos Received
1
Solution
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1205 | 12-11-2017 10:24 PM |
12-11-2017
10:24 PM
In fact, this is the combined effect of two issues: <1> The atlas.war file was not extracted properly during the Atlas installation. So, manually do so, as detailed here: https://community.hortonworks.com/questions/104751/index.html <2> The bug AMBARI-18368 caused a number of Atlas configuration files to be absent from their intended locations. The instructions to address this issue is here: https://issues.apache.org/jira/browse/AMBARI-18368 Now, Atlas is up, finally.
... View more
11-30-2017
08:01 AM
I just installed Atlas 0.8 on an HDP 2.6.0 cluster, which was recently upgraded from HDP 2.3.2 and Kerberized. Yet Atlas 0.8's Metadata Server wouldn't start, with these error messages: KeeperErrorCode = NoNode for /infra-solr/collections/vertex_index
org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /infra-solr/collections/vertex_index
at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.getACL(ZooKeeper.java:1330)
at org.apache.ambari.logsearch.solr.util.AclUtils.setRecursivelyOn(AclUtils.java:76)
at org.apache.ambari.logsearch.solr.util.AclUtils.setRecursivelyOn(AclUtils.java:70)
at org.apache.ambari.logsearch.solr.commands.SecureZNodeZkCommand.executeZkCommand(SecureZNodeZkCommand.java:45)
at org.apache.ambari.logsearch.solr.commands.SecureZNodeZkCommand.executeZkCommand(SecureZNodeZkCommand.java:32)
at org.apache.ambari.logsearch.solr.commands.AbstractZookeeperRetryCommand.createAndProcessRequest(AbstractZookeeperRetryCommand.java:38)
at org.apache.ambari.logsearch.solr.commands.AbstractRetryCommand.retry(AbstractRetryCommand.java:45)
at org.apache.ambari.logsearch.solr.commands.AbstractRetryCommand.run(AbstractRetryCommand.java:40)
at org.apache.ambari.logsearch.solr.AmbariSolrCloudClient.secureZnode(AmbariSolrCloudClient.java:177)
at org.apache.ambari.logsearch.solr.AmbariSolrCloudCLI.main(AmbariSolrCloudCLI.java:522) The zookeeper-client indicates that the znode /infra-solr/configs/atlas_configs does exist, yet none of the Atlas's intended collections (namely, vertex_index, edge_index, and fulltext_index) were created. I attempted to delete the znode /infra-solr/configs/atlas_configs and start from scratch, but I was blocked by an authentication error, as shown below: rmr /infra-solr/configs/atlas_configs Authentication is not valid : /infra-solr/configs/atlas_configs/solrconfig.xml So, how am I going to get out of this? For reference, here is the sequence of operations performed on the cluster: <1> Starting Point: HDP 2.3.2 managed by Ambari Server 2.1.2. <2> Upgraded Ambari Server to 2.5.2.0. <3> Installed Ambari Infra (including Solr). <4> Deleted Atlas 0.5.0. <5> Implemented Kerberos. <6> Upgraded to HDP 2.6.0. <7> Installed Atlas 0.8.0. Now, is it possible that the znode /infra-solr/configs/atlas_configs was actually created by Atlas 0.5.0 when the cluster was still on HDP 2.3.2? (Which is probably why I cannot authenticate and delete it?) Many thanks!
... View more
Labels:
- Labels:
-
Apache Atlas
11-14-2017
07:26 PM
I am upgrading from HDP 2.3.2 to HDP 2.6.0. Should I remove Atlas before the actual HDP cluster upgrade? Thanks. In the HDP 2.6.0 "Apache Ambari Upgrade" (dated April 3, 2017), there is an "Atlas Check" section on page 36. The document says, "If you are upgrading to HDP 2.5 and have Atlas installed in your HDP 2.3 or 2.4 cluster, Atlas must be removed prior to upgrading to HDP 2.5 after you have upgraded to Ambari-2.4.x." Here is my scenario: <1> I am upgrading to HDP 2.6.0 (not 2.5). <2> I have Atlas installed in my HDP 2.3.2 cluster. <3> I just upgraded to Ambari-2.5.2 (not 2.4.x). I suppose the answer is "Yes, remove Atlas now, and add it after the upgrade to HDP 2.6.0". But I just want to double-check and be sure. Thanks again.
... View more
Labels:
11-14-2017
06:08 AM
A few days ago, I happened to run into this issue myself. The root cause is, when installing Ranger, in the "External URL" property, the administrator entered "http://hostname.example.com:6080/", instead of the expected "http://hostname.example.com:6080" (WITHOUT the trailing slash character). Even though the Ranger installation would go through, Ranger's Usersync would log errors in /var/log/ranger/usersync/usersync.log due to this extraneous character. Also, any attempt to enable any of Ranger's plugins would fail, with the error message "Ambari admin username and password are blank", because Ranger is indeed missing many users, including the important one amb_ranger_admin. To fix this, just edit this property and remove any character after port 6080, and everything will start working.
... View more