[
https://issues.apache.org/jira/browse/ATLAS-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16267205#comment-16267205
]
Pierre Padovani edited comment on ATLAS-2270 at 11/27/17 9:15 PM:
------------------------------------------------------------------
Not everyone wants to be tied to using Hadoop/HDFS as part of their
infrastructure. :D
The issue I linked to contains the changes required to the pom.xml for Janus to
enable Cassandra support. The only other thing needed is documentation around
how to set it up. I've built up standalone docker images that contain:
- zookeeper
- cassandra
- Elasticsearch
- atlas (Janus 0.1.0 - working to build 0.2.0 now)
We currently deploy these images for development while we prepare to roll Atlas
in this same configuration.
I'm happy to contribute what else may be needed in this regard.
NOTE: That issue's pom.xml does not work with 0.2.0 of Janus, I'll update it
when I have it working locally. I have configured everything in what I believe
should work, but am getting an error:
{code:java}
Caused by: org.elasticsearch.client.ResponseException: PUT
http://127.0.0.1:9200/janusgraph_vertex_index/_mapping/vertex_index: HTTP/1.1
400 Bad Request
{"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"Can't
merge a non object mapping [__type] with an object mapping
[__type]"}],"type":"illegal_argument_exception","reason":"Can't merge a non
object mapping [__type] with an object mapping [__type]"},"status":400}
at org.elasticsearch.client.RestClient$1.completed(RestClient.java:354)
~[rest-5.5.3.jar:5.5.3]
at org.elasticsearch.client.RestClient$1.completed(RestClient.java:343)
~[rest-5.5.3.jar:5.5.3]
at
org.apache.http.concurrent.BasicFuture.completed(BasicFuture.java:119)
~[httpcore-4.4.1.jar:4.4.1]
at
org.apache.http.impl.nio.client.DefaultClientExchangeHandlerImpl.responseCompleted(DefaultClientExchangeHandlerImpl.java:177)
~[httpasyncclient-4.1.2.jar:4.1.2]
at
org.apache.http.nio.protocol.HttpAsyncRequestExecutor.processResponse(HttpAsyncRequestExecutor.java:436)
~[httpcore-nio-4.4.5.jar:4.4.5]
at
org.apache.http.nio.protocol.HttpAsyncRequestExecutor.inputReady(HttpAsyncRequestExecutor.java:326)
~[httpcore-nio-4.4.5.jar:4.4.5]
at
org.apache.http.impl.nio.client.InternalRequestExecutor.inputReady(InternalRequestExecutor.java:83)
~[httpasyncclient-4.1.2.jar:4.1.2]
at
org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:265)
~[httpcore-nio-4.4.5.jar:4.4.5]
at
org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:81)
~[httpasyncclient-4.1.2.jar:4.1.2]
at
org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:39)
~[httpasyncclient-4.1.2.jar:4.1.2]
at
org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:114)
~[httpcore-nio-4.4.5.jar:4.4.5]
at
org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162)
~[httpcore-nio-4.4.5.jar:4.4.5]
at
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337)
~[httpcore-nio-4.4.5.jar:4.4.5]
at
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
~[httpcore-nio-4.4.5.jar:4.4.5]
{code}
I'll dig in and see if I can figure out what is going on. This combination does
work with Janus 0.1.0.
was (Author: ppadovani):
Not everyone wants to be tied to using Hadoop/HDFS as part of their
infrastructure. :D
The issue I linked to contains the changes required to the pom.xml for Janus to
enable Cassandra support. The only other thing needed is documentation around
how to set it up. I've built up standalone docker images that contain:
- zookeeper
- cassandra
- Elasticsearch
- atlas (Janus 0.1.0 - working to build 0.2.0 now)
We currently deploy these images for development while we prepare to roll Atlas
in this same configuration.
I'm happy to contribute what else may be needed in this regard.
NOTE: That issue's pom.xml does not work with 0.2.0 of Janus, I'll update it
when I have it working locally.
> Supported combinations of persistent store and index backend
> ------------------------------------------------------------
>
> Key: ATLAS-2270
> URL: https://issues.apache.org/jira/browse/ATLAS-2270
> Project: Atlas
> Issue Type: Bug
> Reporter: Graham Wallis
>
> We need to discuss and decide which combinations of persistent store and
> indexing backend Atlas 1.0.0 (master) should support. This includes
> building/running Atlas as a standalone package and running UTs/ITs as part of
> the Atlas build.
> This JIRA focusses on titan0 and janusgraph 0.2.0, as they are the graph
> databases that will be supported in master/1.0.0. This JIRA deliberately
> ignores titan1 and janusgraph 0.1.1 as the former should be
> deprecated/removed and the other is a transient state as we get to janusgraph
> 0.2.0.
> With titan0 as the graph provider, Atlas has supported the following
> combinations of persistent store and indexer. It is suggested that this set
> is kept unchanged:
> {{
> titan0 solr es
> ------------------------------------
> berkeley 0 1
> hbase 1 0
> cassandra 0 0
> }}
> With janusgraph (0.2.0) as the graph provider, Atlas *could* support
> additional combinations. Cassandra is included in this discussion pending
> response to ATLAS-2259.
> {{
> janus 0.2.0 solr es
> ------------------------------------
> berkeley ? 1
> hbase 1 ?
> cassandra ? ?
> }}
> It is suggested that the combinations marked with '1' should be continued and
> the remaining 4 combinations, marked with '?', should be considered. There
> seems to be evidence of people using all 4 of these combinations, although
> not necessarily with Atlas.
> Depending on the decision made above, we need to ensure that it is possible
> to build Atlas as a standalone package with any of the combinations - i.e.
> that they are mutually exclusive and do not interfere with one another. They
> currently interfere which makes it impossible to build Atlas with
> -Pdist,berkeley-elasticsearch because the 'dist' profile will exclude jars
> that are needed by the berkeley-elasticsearch profile - which leads to class
> not found exceptions when the Atlas server is started. The solution to this
> could be very simple, or slightly more sophisticated, depending on how many
> of the combinations we choose to support.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
