Review Request 72766: ATLAS-3920 : Harmonize joda-time to version 2.10.latest.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/72766/ --- Review request for atlas, Madhan Neethiraj and Sarath Subramanian. Bugs: ATLAS-3920 https://issues.apache.org/jira/browse/ATLAS-3920 Repository: atlas Description --- Atlas currently uses outdated joda-time versions, which can cause issues. To avoid issue we need to update it to the latest version of joda-time. Diffs - pom.xml 5e0442a Diff: https://reviews.apache.org/r/72766/diff/1/ Testing --- The test cases passed and also tested basic features and they worked. Thanks, mayank jain
[jira] [Created] (ATLAS-3920) Harmonize joda-time to version 2.10.latest
Mayank Jain created ATLAS-3920: -- Summary: Harmonize joda-time to version 2.10.latest Key: ATLAS-3920 URL: https://issues.apache.org/jira/browse/ATLAS-3920 Project: Atlas Issue Type: Bug Reporter: Mayank Jain Atlas currently uses outdated joda-time versions, which can cause issues. To avoid issue we need to update it to the latest version of joda-time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ATLAS-3875) Adding missing APIs in AtlasClient with test cases
[ https://issues.apache.org/jira/browse/ATLAS-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jyoti Singh updated ATLAS-3875: --- Attachment: ATLAS-3875-2.patch > Adding missing APIs in AtlasClient with test cases > -- > > Key: ATLAS-3875 > URL: https://issues.apache.org/jira/browse/ATLAS-3875 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.0.0, 2.1.0 >Reporter: Jyoti Singh >Assignee: Jyoti Singh >Priority: Major > Labels: api, client > Fix For: 3.0.0, 2.2.0 > > Attachments: ATLAS-3875-1.patch, ATLAS-3875-2.patch, > ATLAS-3875-4.patch > > > 1. There are many new APIs added to Atlas Project but the corresponding APIs > are missing from AtlasClientv2. The aim of this task is to complete the gap > amongst existing APIs and their endpoints in Atls client. This will also > include adding test cases via integration testing. > There are functions from AtlasClient for the following REST endpoints > * TypeRest > * EntityRest > * LineageRest > * DiscoveryRest > * GlossaryRest > * RelationshipRest > 2. Added Sample-Project to showcase how to integrate with Atlas using > AtlasCleint. This helps the user to understand the basic rest functionality > of Atlas. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ATLAS-3900) UI: Allow user to select the date range for date attribute in basic search
[ https://issues.apache.org/jira/browse/ATLAS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176583#comment-17176583 ] Sarath Subramanian commented on ATLAS-3900: --- Thanks for the patch [~kevalbhatt]. +1. > UI: Allow user to select the date range for date attribute in basic search > -- > > Key: ATLAS-3900 > URL: https://issues.apache.org/jira/browse/ATLAS-3900 > Project: Atlas > Issue Type: Sub-task > Components: atlas-webui >Affects Versions: 2.1.0 >Reporter: Keval Bhatt >Assignee: Keval Bhatt >Priority: Major > Labels: basic-search, datetimepicker > Fix For: 3.0.0, 2.2.0 > > Attachments: ATLAS-3900-1.patch, ATLAS-3900-2.patch, > ATLAS-3900-3.patch, ATLAS-3900.patch, Screen Shot 2020-07-21 at 10.59.59 > PM.png, Screen Shot 2020-07-21 at 11.00.08 PM.png, Screen Shot 2020-07-21 at > 11.00.15 PM.png > > > In basic search attribute popup if the user selects the date type attribute > then UI should show a few quick search operator and custom range selection. > example: > !Screen Shot 2020-07-21 at 10.59.59 PM.png|width=631,height=282! > > !Screen Shot 2020-07-21 at 11.00.08 PM.png|width=630,height=302! > > !Screen Shot 2020-07-21 at 11.00.15 PM.png|width=630,height=304! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ATLAS-3919) Handling classification propagation as deferred-action
[ https://issues.apache.org/jira/browse/ATLAS-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarath Subramanian updated ATLAS-3919: -- Affects Version/s: 2.0.0 2.1.0 > Handling classification propagation as deferred-action > -- > > Key: ATLAS-3919 > URL: https://issues.apache.org/jira/browse/ATLAS-3919 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.0.0, 2.1.0 >Reporter: Jayendra Parab >Assignee: Jayendra Parab >Priority: Major > > Currently, whenever a user assigns a tag or updates a tag on an entity, it > gets propagated to all the entities derived from the tagged entity. This > operation takes quite a lot of time to complete (sometimes into minutes) and > causes usability issues on the UI and other clients invoking the REST API > To resolve this issue, tag-propagation needs to be handled as > deferred-action, so that time consuming like propagation, audits & > notifications can be processed in background threads -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ATLAS-3917) While deleting parent tag, shows incorrect message.
[ https://issues.apache.org/jira/browse/ATLAS-3917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chaitali borole reassigned ATLAS-3917: -- Assignee: chaitali borole > While deleting parent tag, shows incorrect message. > --- > > Key: ATLAS-3917 > URL: https://issues.apache.org/jira/browse/ATLAS-3917 > Project: Atlas > Issue Type: Bug >Affects Versions: 2.1.0 >Reporter: Durga Kadam >Assignee: chaitali borole >Priority: Minor > Fix For: 3.0.0 > > Attachments: tag_with_{0}_reproducible.mkv > > > Actual Behaviour - While deleting parent tag if the tag is not associated > with any entity shows this message :: "Failed to delete classification > 'parent_abc'. Given type \{0} has reference." > Expected Result - There should be value instead of \{0} > Steps to generate > # Create tag with sub classification. > # Don't associate the created parent tag with any of the entity > # Try to delete the parent tag > # Shows validation message with some encrypted value > > PFA Evidence file -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ATLAS-3917) While deleting parent tag, shows incorrect message.
[ https://issues.apache.org/jira/browse/ATLAS-3917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chaitali borole updated ATLAS-3917: --- Description: Actual Behaviour - While deleting parent tag if the tag is not associated with any entity shows this message :: "Failed to delete classification 'parent_abc'. Given type \{0} has reference." Expected Result - There should be value instead of \{0} Steps to generate # Create tag with sub classification. # Don't associate the created parent tag with any of the entity # Try to delete the parent tag # Shows validation message with some encrypted value PFA Evidence file was: Actual Behaviour - While deleting parent tag if the tag is associated with any entity shows this message :: "Failed to delete classification 'parent_abc'. Given type \{0} has reference." Expected Result - There should be value instead of \{0} Steps to generate # Create tag # Associate the created tag with any of the entity # Try to delete the tag # Shows validation message with some encrypted value PFA Evidence file > While deleting parent tag, shows incorrect message. > --- > > Key: ATLAS-3917 > URL: https://issues.apache.org/jira/browse/ATLAS-3917 > Project: Atlas > Issue Type: Bug >Affects Versions: 2.1.0 >Reporter: Durga Kadam >Priority: Minor > Fix For: 3.0.0 > > Attachments: tag_with_{0}_reproducible.mkv > > > Actual Behaviour - While deleting parent tag if the tag is not associated > with any entity shows this message :: "Failed to delete classification > 'parent_abc'. Given type \{0} has reference." > Expected Result - There should be value instead of \{0} > Steps to generate > # Create tag with sub classification. > # Don't associate the created parent tag with any of the entity > # Try to delete the parent tag > # Shows validation message with some encrypted value > > PFA Evidence file -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ATLAS-3900) UI: Allow user to select the date range for date attribute in basic search
[ https://issues.apache.org/jira/browse/ATLAS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keval Bhatt updated ATLAS-3900: --- Attachment: ATLAS-3900-3.patch > UI: Allow user to select the date range for date attribute in basic search > -- > > Key: ATLAS-3900 > URL: https://issues.apache.org/jira/browse/ATLAS-3900 > Project: Atlas > Issue Type: Sub-task > Components: atlas-webui >Affects Versions: 2.1.0 >Reporter: Keval Bhatt >Assignee: Keval Bhatt >Priority: Major > Labels: basic-search, datetimepicker > Fix For: 3.0.0, 2.2.0 > > Attachments: ATLAS-3900-1.patch, ATLAS-3900-2.patch, > ATLAS-3900-3.patch, ATLAS-3900.patch, Screen Shot 2020-07-21 at 10.59.59 > PM.png, Screen Shot 2020-07-21 at 11.00.08 PM.png, Screen Shot 2020-07-21 at > 11.00.15 PM.png > > > In basic search attribute popup if the user selects the date type attribute > then UI should show a few quick search operator and custom range selection. > example: > !Screen Shot 2020-07-21 at 10.59.59 PM.png|width=631,height=282! > > !Screen Shot 2020-07-21 at 11.00.08 PM.png|width=630,height=302! > > !Screen Shot 2020-07-21 at 11.00.15 PM.png|width=630,height=304! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ATLAS-3916) Get metrics according to the user permissions
[ https://issues.apache.org/jira/browse/ATLAS-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176262#comment-17176262 ] Yue Dong edited comment on ATLAS-3916 at 8/12/20, 11:03 AM: [~sarath] I get you point. I've tried to add the new functionality. The biggest problem I had was checking permissions of field EntityId (value of entity-unique attribute). It's what you comment, individual entities need to be checked according user permissions. So I had to add one more method to authorization interface, which * checks the permissions of AtlasPrivilege, entityTypes and classifications * and, if everything goes well, it will return a subquery that allows to scrub the entities which the user doesn't have access. With the new method, * when it is a user with EntityId restriction, the count query will be: _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (public_data* OR module_a*)_ * and when it is admin, the query will be: (Maybe it'd be better without _AND $v$"Referenceable.qualifiedName" : *_) _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : *_ And the new behavior of the method getMetrics is: * if the user does't have entities read or types permissions, the count query will not be executed. * if the user has restriction, like EntityId, the count query will be executed with authorization subquery. At the moment it seems to work fine for my requirement. Maybe I miss something, I can show you the code with a wip pull request if you want. I would like to help with this requirement. was (Author: yued): [~sarath] I get you point. I've tried to add the new functionality. The biggest problem I had was checking permissions of field EntityId (value of entity-unique attribute). It's what you comment, individual entities need to be checked according user permissions. So I had to add one more method to authorization interface, which * checks the permissions of AtlasPrivilege, entityTypes and classifications * and, if everything goes well, it will return a subquery that allows to scrub the entities which the user doesn't have access. With the new method, * when it is a user with EntityId restriction, the count query will be: _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (public_data* OR module_a*)_ * and when it is admin, the query will be: (Maybe it'd be better without _AND $v$"Referenceable.qualifiedName" : (*)_) _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (*)_ And the new behavior of the method getMetrics is: * if the user does't have entities read or types permissions, the count query will not be executed. * if the user has restriction, like EntityId, the count query will be executed with authorization subquery. At the moment it seems to work fine for my requirement. Maybe I miss something, I can show you the code with a wip pull request if you want. I would like to help with this requirement. > Get metrics according to the user permissions > - > > Key: ATLAS-3916 > URL: https://issues.apache.org/jira/browse/ATLAS-3916 > Project: Atlas > Issue Type: New Feature > Components: atlas-core >Affects Versions: 2.0.0, 2.1.0 >Reporter: Yue Dong >Priority: Major > Attachments: Captura-de-pantalla-de-2020-08-11-10-20-06.png > > > I have two user groups: admin who has access to all tables and reader can > only see public data and module A tables. So I have configured Atlas to use a > simple authorizer with a little variation, which is to hide entities that are > not accessible to the user. > The searches and displaying results work properly. > The only problem I find is that the metrics. In the elements of search by > type, it indicates the number of all the entities of each type in the system. > And this is not consistent with the search result of a reader user. > !Captura-de-pantalla-de-2020-08-11-10-20-06.png! > > I have verified that these numbers come from the getMetrics method, which is > not secured so it does not obtain the numbers according to the users' > configuration. Am I missing something? Is there any way to change these > numbers? > Maybe it'd be nice to have something that allows to modify the querys of the > metrics based on security and authorization, like > AtlasAuthorizer.scrubSearchResults in search methods. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ATLAS-3916) Get metrics according to the user permissions
[ https://issues.apache.org/jira/browse/ATLAS-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176262#comment-17176262 ] Yue Dong edited comment on ATLAS-3916 at 8/12/20, 11:02 AM: [~sarath] I get you point. I've tried to add the new functionality. The biggest problem I had was checking permissions of field EntityId (value of entity-unique attribute). It's what you comment, individual entities need to be checked according user permissions. So I had to add one more method to authorization interface, which * checks the permissions of AtlasPrivilege, entityTypes and classifications * and, if everything goes well, it will return a subquery that allows to scrub the entities which the user doesn't have access. With the new method, * when it is a user with EntityId restriction, the count query will be: _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (public_data* OR module_a*)_ * and when it is admin, the query will be: (Maybe it'd be better without _AND $v$"Referenceable.qualifiedName" : (*)_) _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (*)_ And the new behavior of the method getMetrics is: * if the user does't have entities read or types permissions, the count query will not be executed. * if the user has restriction, like EntityId, the count query will be executed with authorization subquery. At the moment it seems to work fine for my requirement. Maybe I miss something, I can show you the code with a wip pull request if you want. I would like to help with this requirement. was (Author: yued): [~sarath] I get you point. I've tried to add the new functionality. The biggest problem I had was checking permissions of field EntityId (value of entity-unique attribute). It's what you comment, individual entities need to be checked according user permissions. So I had to add one more method to authorization interface, which * checks the permissions of AtlasPrivilege, entityTypes and classifications * and, if everything goes well, it will return a subquery that allows to scrub the entities which the user doesn't have access. With the new method, * when it is a user with EntityId restriction, the count query will be: _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (public_data* OR module_a*)_ * and when it is admin, the query will be: (Maybe it'd be better without _AND $v$"Referenceable.qualifiedName" : (*)_) _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (*)_ And the new behavior of the method getMetrics is: * if the user does't have entities read or types permissions, the count query will not be executed. * if the user has restriction, like EntityId, the count query will be executed with authorization subquery. At the moment it seems to work fine for my requirement. Maybe I miss something, I can show you the code with a wip pull request if you want. I would like to help with this requirement. > Get metrics according to the user permissions > - > > Key: ATLAS-3916 > URL: https://issues.apache.org/jira/browse/ATLAS-3916 > Project: Atlas > Issue Type: New Feature > Components: atlas-core >Affects Versions: 2.0.0, 2.1.0 >Reporter: Yue Dong >Priority: Major > Attachments: Captura-de-pantalla-de-2020-08-11-10-20-06.png > > > I have two user groups: admin who has access to all tables and reader can > only see public data and module A tables. So I have configured Atlas to use a > simple authorizer with a little variation, which is to hide entities that are > not accessible to the user. > The searches and displaying results work properly. > The only problem I find is that the metrics. In the elements of search by > type, it indicates the number of all the entities of each type in the system. > And this is not consistent with the search result of a reader user. > !Captura-de-pantalla-de-2020-08-11-10-20-06.png! > > I have verified that these numbers come from the getMetrics method, which is > not secured so it does not obtain the numbers according to the users' > configuration. Am I missing something? Is there any way to change these > numbers? > Maybe it'd be nice to have something that allows to modify the querys of the > metrics based on security and authorization, like > AtlasAuthorizer.scrubSearchResults in search methods. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ATLAS-3916) Get metrics according to the user permissions
[ https://issues.apache.org/jira/browse/ATLAS-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176262#comment-17176262 ] Yue Dong commented on ATLAS-3916: - [~sarath] I get you point. I've tried to add the new functionality. The biggest problem I had was checking permissions of field EntityId (value of entity-unique attribute). It's what you comment, individual entities need to be checked according user permissions. So I had to add one more method to authorization interface, which * checks the permissions of AtlasPrivilege, entityTypes and classifications * and, if everything goes well, it will return a subquery that allows to scrub the entities which the user doesn't have access. With the new method, * when it is a user with EntityId restriction, the count query will be: _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (public_data* OR module_a*)_ * and when it is admin, the query will be: (Maybe it'd be better without _AND $v$"Referenceable.qualifiedName" : (*)_) _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (*)_ And the new behavior of the method getMetrics is: * if the user does't have entities read or types permissions, the count query will not be executed. * if the user has restriction, like EntityId, the count query will be executed with authorization subquery. At the moment it seems to work fine for my requirement. Maybe I miss something, I can show you the code with a wip pull request if you want. I would like to help with this requirement. > Get metrics according to the user permissions > - > > Key: ATLAS-3916 > URL: https://issues.apache.org/jira/browse/ATLAS-3916 > Project: Atlas > Issue Type: New Feature > Components: atlas-core >Affects Versions: 2.0.0, 2.1.0 >Reporter: Yue Dong >Priority: Major > Attachments: Captura-de-pantalla-de-2020-08-11-10-20-06.png > > > I have two user groups: admin who has access to all tables and reader can > only see public data and module A tables. So I have configured Atlas to use a > simple authorizer with a little variation, which is to hide entities that are > not accessible to the user. > The searches and displaying results work properly. > The only problem I find is that the metrics. In the elements of search by > type, it indicates the number of all the entities of each type in the system. > And this is not consistent with the search result of a reader user. > !Captura-de-pantalla-de-2020-08-11-10-20-06.png! > > I have verified that these numbers come from the getMetrics method, which is > not secured so it does not obtain the numbers according to the users' > configuration. Am I missing something? Is there any way to change these > numbers? > Maybe it'd be nice to have something that allows to modify the querys of the > metrics based on security and authorization, like > AtlasAuthorizer.scrubSearchResults in search methods. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ATLAS-3561) Atlas start fails in embedded-hbase mode with zookeeper error
[ https://issues.apache.org/jira/browse/ATLAS-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chaitali borole updated ATLAS-3561: --- Description: After compiling Atlas with {{mvn clean package -Pdist,embedded-hbase-solr}} and starting Atlas with embedded services hbase, solr and kafka using {{atlas_start.py}}, the Atlas start fails with below error in {{application.log}} {noformat} 2019-12-09 16:01:28,839 INFO - [main:] ~ Not running setup per configuration atlas.server.run.setup.on.start. (SetupSteps$SetupRequired:189) 2019-12-09 16:01:32,786 WARN - [ReadOnlyZKClient-localhost:2181@0x0fa5f81c-SendThread(localhost:2181):] ~ Session 0x16eea36b27b0003 for server null, unexpected error, closing socket connection and attempting reconnect (ClientCnxn$SendThread:1102) java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081) 2019-12-09 16:01:32,889 WARN - [ReadOnlyZKClient-localhost:2181@0x0fa5f81c:] ~ 0x0fa5f81c to localhost:2181 failed for get of /hbase/meta-region-server, code = CONNECTIONLOSS, retries = 1 (ReadOnlyZKClient$ZKTask$1:183) 2019-12-09 16:01:34,004 WARN - [ReadOnlyZKClient-localhost:2181@0x0fa5f81c-SendThread(localhost:2181):] ~ Session 0x16eea36b27b0003 for server null, unexpected error, closing socket connection and attempting reconnect (ClientCnxn$SendThread:1102) java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081) {noformat} *Workaround* Adding below property in {{hbase-site.xml.template}} and running {{mvn clean package -Pdist,embedded-hbase-solr}} the issue is resolved. Path : /home/\{computername}/atlas/distro/target/apache-atlas-3.0.0-SNAPSHOT-bin/apache-atlas-3.0.0-SNAPSHOT/hbase/conf {code:none} hbase.unsafe.stream.capability.enforce false {code} was: After compiling Atlas with {{mvn clean package -Pdist,embedded-hbase-solr}} and starting Atlas with embedded services hbase, solr and kafka using {{atlas_start.py}}, the Atlas start fails with below error in {{application.log}} {noformat} 2019-12-09 16:01:28,839 INFO - [main:] ~ Not running setup per configuration atlas.server.run.setup.on.start. (SetupSteps$SetupRequired:189) 2019-12-09 16:01:32,786 WARN - [ReadOnlyZKClient-localhost:2181@0x0fa5f81c-SendThread(localhost:2181):] ~ Session 0x16eea36b27b0003 for server null, unexpected error, closing socket connection and attempting reconnect (ClientCnxn$SendThread:1102) java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081) 2019-12-09 16:01:32,889 WARN - [ReadOnlyZKClient-localhost:2181@0x0fa5f81c:] ~ 0x0fa5f81c to localhost:2181 failed for get of /hbase/meta-region-server, code = CONNECTIONLOSS, retries = 1 (ReadOnlyZKClient$ZKTask$1:183) 2019-12-09 16:01:34,004 WARN - [ReadOnlyZKClient-localhost:2181@0x0fa5f81c-SendThread(localhost:2181):] ~ Session 0x16eea36b27b0003 for server null, unexpected error, closing socket connection and attempting reconnect (ClientCnxn$SendThread:1102) java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081) {noformat} *Workaround* Adding below property in {{hbase-site.xml.template}} and running {{mvn clean package -Pdist,embedded-hbase-solr}} the issue is resolved. {code:none} hbase.unsafe.stream.capability.enforce false {code} > Atlas start fails in embedded-hbase mode with zookeeper error > - > > Key: ATLAS-3561 > URL: https://issues.apache.org/jira/browse/ATLAS-3561 > Project: Atlas > Issue Type: Bug > Components: atlas-core >Affects Versions: 3.0.0 >Reporter: chaitali borole >Assignee: chaitali borole >Priority: