You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "Alejandro Fernandez (JIRA)" <ji...@apache.org> on 2016/09/15 01:42:20 UTC

[jira] [Comment Edited] (AMBARI-18368) Atlas web UI alert after performing stack upgrade to HDP 2.5 and adding Atlas Service

    [ https://issues.apache.org/jira/browse/AMBARI-18368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491816#comment-15491816 ] 

Alejandro Fernandez edited comment on AMBARI-18368 at 9/15/16 1:41 AM:
-----------------------------------------------------------------------

There's an additional problem when Hive exists in HDP 2.4 and Atlas is not present.

The Hive RPM installs /usr/$stack/$version/atlas with some partial packages that contain Hive hooks, while the Atlas RPM is responsible for installing the full content.
If the user does not have Atlas currently installed on their stack, then /usr/$stack/current/atlas-clientwill be a broken symlink, and we should not create the symlink /etc/atlas/conf -> /usr/$stack/current/atlas-client/conf .
If we mistakenly create this symlink, then when the user performs an EU/RU and then adds Atlas service then the Atlas RPM will not be able to copy its artifacts into /etc/atlas/conf directory and therefore prevent Ambari from by copying those unmanaged contents into /etc/atlas/$version/0

Further, when installing Atlas service, we must copy the artifacts from /etc/atlas/conf.backup/* to /etc/atlas/conf (which is now a symlink to /usr/hdp/current/atlas-client/conf/) with the no-clobber flag.

Will reopen this Jira to provide an addendum patch for this related scenario.


was (Author: afernandez):
There's an additional problem when Hive exists in HDP 2.4 and Atlas is not present.

The Hive RPM installs /usr/$stack/$version/atlas with some partial packages that contain Hive hooks, while the Atlas RPM is responsible for installing the full content.
If the user does not have Atlas currently installed on their stack, then /usr/$stack/current/atlas-clientwill be a broken symlink, and we should not create the symlink /etc/atlas/conf -> /usr/$stack/current/atlas-client/conf .
If we mistakenly create this symlink, then when the user performs an EU/RU and then adds Atlas service then the Atlas RPM will not be able to copy its artifacts into /etc/atlas/conf directory and therefore prevent Ambari from by copying those unmanaged contents into /etc/atlas/$version/0

Will reopen this Jira to provide an addendum patch for this related scenario.

> Atlas web UI alert after performing stack upgrade to HDP 2.5 and adding Atlas Service
> -------------------------------------------------------------------------------------
>
>                 Key: AMBARI-18368
>                 URL: https://issues.apache.org/jira/browse/AMBARI-18368
>             Project: Ambari
>          Issue Type: Bug
>          Components: stacks
>    Affects Versions: 2.4.0
>            Reporter: Alejandro Fernandez
>            Assignee: Alejandro Fernandez
>            Priority: Critical
>             Fix For: trunk, 2.4.2
>
>         Attachments: AMBARI-18368.patch
>
>
> Steps to Reproduce:
> * Install Ambari 2.2.2 with HDP 2.4 and HBase, Kafka, and Hive (this is very important)
> * Kerberize the cluster
> * Perform EU/RU to HDP 2.5
> * Add Atlas Service
> Atlas Server log contains,
> {code}
> Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://natu146-ehbs-dgm10toeriesec-u14-1.openstacklocal:8886/solr: Can not find the specified config set: vertex_index
>         at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:577)
>         at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
>         at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
>         at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372)
>         at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325)
>         at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
>         at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
>         at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
>         at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
>         at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
>         at com.thinkaurelius.titan.diskstorage.solr.Solr5Index.createCollectionIfNotExists(Solr5Index.java:901)
>         at com.thinkaurelius.titan.diskstorage.solr.Solr5Index.register(Solr5Index.java:269)
>         at com.thinkaurelius.titan.diskstorage.indexing.IndexTransaction.register(IndexTransaction.java:83)
>         at com.thinkaurelius.titan.graphdb.database.IndexSerializer.register(IndexSerializer.java:92)
>         at com.thinkaurelius.titan.graphdb.database.management.ManagementSystem.addIndexKey(ManagementSystem.java:534)
>         at org.apache.atlas.repository.graph.GraphBackedSearchIndexer.enhanceMixedIndex(GraphBackedSearchIndexer.java:405)
>         at org.apache.atlas.repository.graph.GraphBackedSearchIndexer.createIndexes(GraphBackedSearchIndexer.java:334)
>         at org.apache.atlas.repository.graph.GraphBackedSearchIndexer.initialize(GraphBackedSearchIndexer.java:103)
>         ... 71 more
> {code}
> Atlas tables in HBase look ok.
> {code}
> su hbase
> kinit -kt /etc/security/keytabs/hbase.headless.keytab cstm-hbase@EXAMPLE.COM
> hbase shell
> hbase(main):001:0> list
> TABLE
> ATLAS_ENTITY_AUDIT_EVENTS
> atlas_titan
> 2 row(s) in 1.4300 seconds
> => ["ATLAS_ENTITY_AUDIT_EVENTS", "atlas_titan"]
> {code}
> h4. Workaround
> 1. Stop Atlas Server
> 2. Copy solr xml files to correct config folder and chown as $atlas_user:$hadoop_group
> {code}
> cp -R /usr/hdp/2.5.0.0-####/etc/atlas/conf.dist/solr/* /etc/atlas/conf/solr/
> cp: overwrite `/etc/atlas/conf/solr/solrconfig.xml'? n
> chown atlas:hadoop /etc/atlas/conf/solr/*
> cp /usr/hdp/2.5.0.0-####/etc/atlas/conf.dist/users-credentials.properties /etc/atlas/conf/
> cp /usr/hdp/2.5.0.0-####/etc/atlas/conf.dist/policy-store.txt /etc/atlas/conf/
> chown atlas:hadoop /etc/atlas/conf/users-credentials.properties
> chown atlas:hadoop /etc/atlas/conf/policy-store.txt
> {code}
> 3. Delete zookeeper znode,
> {code}
> # kinit -kt /etc/security/keytabs/atlas.service.keytab  atlas/<HOST>@<DOMAIN>
> # cd /usr/hdp/current/zookeeper-client/bin/ 
> # ./zkCli.sh -server <zookeepernode>:<zookeeperport>
> [ ...... (CONNECTED) ] rmr  /infra-solr/configs/atlas_configs
> {code}
> 4. Ensure Atlas application-properties are present for,
> atlas.jaas.KafkaClient.option.keyTab = /etc/security/keytabs/atlas.service.keytab
> atlas.jaas.KafkaClient.option.principal = atlas/_HOST@EXAMPLE.COM
> 5. Start Atlas



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)