Date   

Re: [VOTE] JanusGraph 0.6.0 release

Oleksandr Porunov
 

Hi @vinay1331,

This is expected. You must upgrade your Gremlin Server client first. See upgrade instructions regarding your issue here: https://docs.janusgraph.org/master/changelog/#serialization-of-janusgraph-predicates-has-changed
Also, for gremlin settings breaking changes see the following instructions: 
https://docs.janusgraph.org/master/changelog/#breaking-change-for-gremlin-server-configs
https://docs.janusgraph.org/master/changelog/#introduction-of-a-janusgraph-server-startup-class-as-a-replacement-for-gremlin-server-startup
https://docs.janusgraph.org/master/changelog/#automatic-configurations-of-dynamic-graph-binding

Also, notice, the binaries will be updated soon. Thus, you *may* potentially need to update your gremlin server multiple times.

Thanks for taking part in testing.

Best regards,
Oleksandr


Re: [VOTE] JanusGraph 0.6.0 release

vinay1331@...
 

After the upgrade to testing getting following exception using remote traversal. Used tinkerpop 3.5.1 with janusgrah drive-0.6.0


WARN  org.apache.tinkerpop.gremlin.server.handler.WsGremlinBinaryRequestDecoder  - 
Gremlin Server is not configured with a serializer for the 
requested mime type [application/vnd.gremlin-v1.0+gryo] 
- using org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1 by default
2889684 [gremlin-server-worker-1]
 WARN  org.apache.tinkerpop.gremlin.server.handler.OpSelectorHandler  - 
 Invalid OpProcessor requested [null]
org.apache.tinkerpop.gremlin.server.op.OpProcessorException: Invalid OpProcessor requested [null]
        at org.apache.tinkerpop.gremlin.server.handler.OpSelectorHandler.decode(OpSelectorHandler.java:85)
        at org.apache.tinkerpop.gremlin.server.handler.OpSelectorHandler.decode(OpSelectorHandler.java:48)
        at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
        at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
        at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
        at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
        at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
        at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:93)
        at io.netty.handler.codec.http.websocketx.Utf8FrameValidator.channelRead(Utf8FrameValidator.java:82)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
        at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
        at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)


[DISCUSSION] Release snapshot versions on each commit

Oleksandr Porunov
 

I would like to propose to make simple GitHub jar releases on each commit in `master` or `v*` branches. Those releases would be simple GitHub packages and their purpose wouldn't be mostly for easier testing. 
This would also allow users to use latest features from `master` branch without need to build their own version of JanusGraph to use those snapshot versions.

Would be great to hear other opinions about it. Do you think this would be useful for the community or not?

Best regards,
Oleksandr


Re: [VOTE] JanusGraph 0.6.0 release

Boxuan Li
 

Hi thanks for the quick responses. Followed by Clement’s advice, I made a fix https://github.com/li-boxuan/janusgraph/commit/aec47d44e6b0a57eac5fb5acab4c11d365d0ecac that worked on my local laptop. If CI pass I will submit a PR.

Best regards,
Boxuan

On Aug 14, 2021, at 8:15 PM, Oleksandr Porunov <alexandr.porunov@...> wrote:

Thank you Boxuan for the catch!

I will try to look at it today's evening. I have no luck I hope Clement will be able to check it on Monday.

Thus, I'm extending the voting process until the issue is fixed. After the fix I will re-upload artifacts to Sonatype and update release artifacts and a tag.

Best regards,
Oleksandr


Re: [VOTE] JanusGraph 0.6.0 release

Oleksandr Porunov
 

Thank you Boxuan for the catch!

I will try to look at it today's evening. I have no luck I hope Clement will be able to check it on Monday.

Thus, I'm extending the voting process until the issue is fixed. After the fix I will re-upload artifacts to Sonatype and update release artifacts and a tag.

Best regards,
Oleksandr


Re: [VOTE] JanusGraph 0.6.0 release

Clement de Groc
 

Hey Boxuan,

Good catch !

To the best of my knowledge, this type of error usually means there is a mix of scala 2.11 and scala 2.12 libraries.

TinkerPop 3.5 switched to Spark 3 and Scala 2.12 (https://github.com/apache/tinkerpop/blob/master/spark-gremlin/pom.xml#L88).

But I see (at least one) reference to Scala 2.11 libraries in janusgraph-hadoop (https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-hadoop/pom.xml#L77).

I would try chasing down libraries pulling Scala 2.11 and upgrading them.
I can look into that on Monday if noone has before.

Best,
Clement

Le sam. 14 août 2021 à 06:36, Boxuan Li <liboxuan@...> a écrit :
I downloaded https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/janusgraph-0.6.0.zip, tried a simple traversal using SparkGraphComputer on my laptop but failed:

:plugin use tinkerpop.hadoop
:plugin use tinkerpop.spark
graph = GraphFactory.open('conf/hadoop-graph/read-cql.properties')
g = graph.traversal().withComputer(SparkGraphComputer)
g.V().count()
with error `java.lang.NoSuchMethodError: scala.Predef$.refArrayOps([Ljava/lang/Object;)Lscala/collection/mutable/ArrayOps;`

I don't have scala or Spark installed locally. The same traversal worked well on the 0.5.3 version. I personally never ran any workload on Spark before, so I am not sure if this is expected, or due to a library conflict in Janusgraph distribution. If anyone familiar with Spark can shed some light or test by themselves, it would be very helpful. Otherwise, I am afraid 0.6.0 might not work well with Spark.

Best,
Boxuan


Re: [VOTE] JanusGraph 0.6.0 release

Boxuan Li
 

I downloaded https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/janusgraph-0.6.0.zip, tried a simple traversal using SparkGraphComputer on my laptop but failed:

:plugin use tinkerpop.hadoop
:plugin use tinkerpop.spark
graph = GraphFactory.open('conf/hadoop-graph/read-cql.properties')
g = graph.traversal().withComputer(SparkGraphComputer)
g.V().count()
with error `java.lang.NoSuchMethodError: scala.Predef$.refArrayOps([Ljava/lang/Object;)Lscala/collection/mutable/ArrayOps;`

I don't have scala or Spark installed locally. The same traversal worked well on the 0.5.3 version. I personally never ran any workload on Spark before, so I am not sure if this is expected, or due to a library conflict in Janusgraph distribution. If anyone familiar with Spark can shed some light or test by themselves, it would be very helpful. Otherwise, I am afraid 0.6.0 might not work well with Spark.

Best,
Boxuan


Re: [VOTE] JanusGraph 0.6.0 release

Clement de Groc
 

Hey,

I've performed the following tests:
- Built the source code and a docker image from janusgraph-dist/Dockerfile.
- Updated an existing configuration/graph. Followed the upgrade instructions.
- Started JanusGraph and performed simple requests (hitting composite and mixed indices).
- Enabled and checked the presence of CQL metrics and threadpool metrics.

+1 from me.

Clement

On Wed, Aug 11, 2021 at 6:17 PM Rafael Fernandes <luizrafael@...> wrote:
+1
Tested the binaries in our docker instances..

Rafa


On Wed, Aug 11, 2021 at 8:43 AM Oleksandr Porunov <alexandr.porunov@...> wrote:
Hello,

We are happy to announce that JanusGraph 0.6.0 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.6.0

A full binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/janusgraph-full-0.6.0.zip
 
A truncated binary distribution is provided:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/janusgraph-0.6.0.zip
 
The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/janusgraph-0.6.0-doc.zip

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.6.0

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/master/docs/changelog.md#version-060-release-date-august-11-2021

This [VOTE] will open for the next 3 days --- closing Saturday, August 14, 2021 at 3:45 PM GMT+3.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.

Thank you,
Oleksandr Porunov


Re: [VOTE] JanusGraph 0.6.0 release

Rafael Fernandes
 

+1
Tested the binaries in our docker instances..

Rafa


On Wed, Aug 11, 2021 at 8:43 AM Oleksandr Porunov <alexandr.porunov@...> wrote:
Hello,

We are happy to announce that JanusGraph 0.6.0 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.6.0

A full binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/janusgraph-full-0.6.0.zip
 
A truncated binary distribution is provided:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/janusgraph-0.6.0.zip
 
The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/janusgraph-0.6.0-doc.zip

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.6.0

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/master/docs/changelog.md#version-060-release-date-august-11-2021

This [VOTE] will open for the next 3 days --- closing Saturday, August 14, 2021 at 3:45 PM GMT+3.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.

Thank you,
Oleksandr Porunov


Re: [DISCUSS] JanusGraph 0.6.0 release

Oleksandr Porunov
 

The voting is now opened for 0.6.0 release at this location: https://lists.lfaidata.foundation/g/janusgraph-dev/topic/vote_janusgraph_0_6_0/84815207

Best regards,
Oleksandr


[VOTE] JanusGraph 0.6.0 release

Oleksandr Porunov
 

Hello,

We are happy to announce that JanusGraph 0.6.0 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.6.0

A full binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/janusgraph-full-0.6.0.zip
 
A truncated binary distribution is provided:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/janusgraph-0.6.0.zip
 
The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.0/janusgraph-0.6.0-doc.zip

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.6.0

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/master/docs/changelog.md#version-060-release-date-august-11-2021

This [VOTE] will open for the next 3 days --- closing Saturday, August 14, 2021 at 3:45 PM GMT+3.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.

Thank you,
Oleksandr Porunov


Re: [DISCUSS] JanusGraph 0.6.0 release

Oleksandr Porunov
 

The release commit is available for the review here: https://github.com/JanusGraph/janusgraph/pull/2672

Best regards,
Oleksandr 


Re: [DISCUSS] JanusGraph 0.6.0 release

Oleksandr Porunov
 

We will probably need to delay the start of the release to several days because there are some blocking PRs (targeted to 0.6.0 milestone) and I'm not sure we can merge them due to failing EasyCLA. I don't know the way to retrieve signed CLAs for JanusGraph.
Please, refer to the next links:
https://jira.linuxfoundation.org/plugins/servlet/theme/portal/4/SUPPORT-6184
https://github.com/communitybridge/easycla/issues/3090
https://github.com/JanusGraph/janusgraph/milestones/Release%20v0.6.0

As soon as this issues are resolved (or the workaround is found) I will start the release process.
Sorry again for the delay.

Best regards,
Oleksandr 


Re: [DISCUSS] JanusGraph 0.6.0 release

Oleksandr Porunov
 

TinkerPop was updated to version 3.5.1, so now nothing blocks JanusGraph from 0.6.0 release.
I'm proposing to start release process on August 2 (Monday). There are quite a few features which would be great to ship with 0.6.0 release but we are already holding the release for quite some time.
I believe the outstanding work could be shifted to other releases (0.6.1 / 1.0.0, etc.). Potentially we can merge several PRs this week.


[ANNOUNCEMENT] JanusGraph enabled donations on LFX Crowdfunding

Oleksandr Porunov
 

The JanusGraph Technical Steering Committee is excited to announce that JanusGraph is now accepting donations.


As you may know, most of JanusGraph contributors are not full-time JanusGraph employees, thus we came up with the idea to try to collect donations from the community to be able to hire full time employees to JanusGraph.


With your help JanusGraph will be able to produce releases much more often and we will be able to develop JanusGraph much faster.


JanusGraph Technical Steering Committee guarantees to be fully transparent with the community about any penny spent. We are accepting contributions via LFX Crowdfunding which has an open ledger where you can check all the transactions made and their descriptions.


LFX Crowdfunding link where JanusGraph accepts donations is : https://crowdfunding.lfx.linuxfoundation.org/projects/janusgraph


Best regards,

Oleksandr Porunov

on behalf of JanusGraph TSC


New TSC member: Boxuan Li

Oleksandr Porunov
 

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new Technical Steering Committee member on the project!

Boxuan Li has provided major contributions and has demonstrated an on-going commitment to the project. Being a TSC member enables assistance with the project management and to guide the direction of the project.

Congratulations, Boxuan Li!


Re: [DISCUSS] Dropping HBase 1 support

Boxuan Li
 

Hi Jan,

I think you could forward this to the user mailing list as well. Maybe janusgraph-hbase users could shed some light. I personally don’t have any opinion here.

Best,
Boxuan


「<Jan.jansen@...>」在 2021年7月14日 週三,下午4:13 寫道:

Hi

I looked into the Hbase 1 support after Porunov asked why I want to drop if the builds are passing: https://github.com/JanusGraph/janusgraph/pull/2213#issuecomment-861620348. It seems that we stop testing HBase 1 in our CI solution already in branch 0.3. The main issue was a wrong combination of maven flags for stop testing.

I tried to fix the flags and realized that isn't working against the Testcontainers solution, so revert internal back to commit before Testcontainers, see here https://github.com/GDATASoftwareAG/janusgraph/tree/test-hbase1. I had to fix some build issue than was able to execute tests which are failing https://github.com/GDATASoftwareAG/janusgraph/actions/runs/1024212663. (I didn't fix the HBase 2 build)

My Idea would be to drop HBase 1 support. (Currently, HBase 1 support already requires a custom build of JG.)

Any thoughts?

Greetings, Jan


[DISCUSS] Dropping HBase 1 support

Jansen, Jan
 

Hi

I looked into the Hbase 1 support after Porunov asked why I want to drop if the builds are passing: https://github.com/JanusGraph/janusgraph/pull/2213#issuecomment-861620348. It seems that we stop testing HBase 1 in our CI solution already in branch 0.3. The main issue was a wrong combination of maven flags for stop testing.

I tried to fix the flags and realized that isn't working against the Testcontainers solution, so revert internal back to commit before Testcontainers, see here https://github.com/GDATASoftwareAG/janusgraph/tree/test-hbase1. I had to fix some build issue than was able to execute tests which are failing https://github.com/GDATASoftwareAG/janusgraph/actions/runs/1024212663. (I didn't fix the HBase 2 build)

My Idea would be to drop HBase 1 support. (Currently, HBase 1 support already requires a custom build of JG.)

Any thoughts?

Greetings, Jan


Re: [DISCUSS] JanusGraph versioning

Boxuan Li
 

1.0.0 sounds good to me. Maybe we can target 1.0.0 after this 0.6.0 release. I think we'd better not rename the incoming release from 0.6.0 to 1.0.0, because it contains many new changes and may take some time (+ bug fixes, if any) to get stable. I would rather see a stable 1.0.0 release with few new features than an unstable one with many new features.

Best regards,
Boxuan Li


[DISCUSS] JanusGraph versioning

Oleksandr Porunov
 

Hi,

I would like to start a discussion about JanusGraph versioning.
Right now we have the next versioning:
<GA indicator?>.<features and breaking changes>.<patch>

So, for GA indicator we always have `0` and as far as I know we were waiting for JanusGraph to be stable to increment JanusGraph to 1.0.0 version.

That said, I'm not sure how exactly should it be considered as stable.
It was quite some time for JanusGraph to be used in production by many companies.

We could think about stability as:
- JanusGraph has been used in production for some time.
- There are no breaking changes for some time.

I think we meet the first case. I.e. JanusGraph is used in production but I'm not sure about the second option.

We do have breaking changes often but mostly they are related to drop of support for EOL versions or driver upgrades. I guess, we will have such breaking changes continiously because the support for old drivers will be dropped and new drivers will be supported. Thus, such breaking changes are kind of natural thing I guess.
I guess, bigger breaking changes are those, which influence storage layer (i.e. data). Last time we had such breaking changes was in 0.3.0 release (that said, they were very small and easy to be upgraded). So, if we count only such changes where you can't easily upgrade JanusGraph because you have data in old format - we meet second option as well in such situation.

In case we consider JanusGraph to be stable enough, should we upgrade it to 1.x.y version?

If we upgrade it, should we start following something like semantic versioning for all future versions (https://semver.org/) or should we think about different versioning / keep current versioning?

When should we upgrade JanusGraph to 1.x.y?

Should the first version `1.x.y` keep current `x.y` or reset it to `0.0`? I.e. should the first version be `1.7.0` or `1.0.0`?

My thoughts on the above questions are:
- We can consider JanusGraph to be stable enough
- After the upgrade it would make sense to start using the same version number as in semantic versioning (i.e. MAJOR.MINOR.PATCH).
- I guess we could do it on the next release after 0.6.0 but we potentially could rename 0.6.0 to 1.0.0 or 1.6.0 versions as well. I don't have good thoughts on that yet.
- Both 1.0.0 and 1.7.0 / 1.6.0 are good to me. I don't have good thoughts about it yet as well.

To be clear, I'm not insisting to bump JanusGraph to 1.x.y version immediately. What I wanted is to start a discussion about it to see other thoughts.

Best regards,
Oleksandr Porunov

61 - 80 of 1596