|
[VOTE] JanusGraph 0.6.2 release
Florian Hockmann
Hello,
A truncated binary distribution is provided:
The GPG key used to sign the release artifacts is available at:
|
|
|
|
Re: [DISCUSS] JanusGraph 0.6.2 Release
Florian Hockmann
I’ll interpret the lack of replies as lazy consensus and proceed with the release process.
Von: janusgraph-dev@... <janusgraph-dev@...> Im Auftrag von Florian Hockmann
Hi,
it has been nearly 4 months now since we released 0.6.1 and I just merged the PR to update TinkerPop to 3.5.3 [1].
So, I think that it makes to release 0.6.2 soon. Given that the release process is now also partially automated (thanks to Oleksandr’s great work), I’m also more in favour of releasing a maintenance version with only a small number of changes like this one since the release process doesn’t require as much effort anymore.
We should of course wait until the distribution tests work again: https://github.com/JanusGraph/janusgraph/pull/3036
Are there any other issues or PRs that should be included in this release? I at least don’t see any in the milestone for this version right now [2].
Regards, Florian
[1]: https://github.com/JanusGraph/janusgraph/pull/2999 [2]: https://github.com/JanusGraph/janusgraph/milestone/23
|
|
|
|
[DISCUSS] JanusGraph 0.6.2 Release
Florian Hockmann
Hi,
it has been nearly 4 months now since we released 0.6.1 and I just merged the PR to update TinkerPop to 3.5.3 [1].
So, I think that it makes to release 0.6.2 soon. Given that the release process is now also partially automated (thanks to Oleksandr’s great work), I’m also more in favour of releasing a maintenance version with only a small number of changes like this one since the release process doesn’t require as much effort anymore.
We should of course wait until the distribution tests work again: https://github.com/JanusGraph/janusgraph/pull/3036
Are there any other issues or PRs that should be included in this release? I at least don’t see any in the milestone for this version right now [2].
Regards, Florian
[1]: https://github.com/JanusGraph/janusgraph/pull/2999 [2]: https://github.com/JanusGraph/janusgraph/milestone/23
|
|
|
|
Re: [DISCUSS] Discord Server
Florian Hockmann
This thread didn’t really see much activity and I’m not sure how to interpret this. Are people here in favour of switching to Discord but don’t have much else to add to the discussion? Or do you just not care much about it?
But since we now only have two voices in favour of Discord, I’d move the discussion next to janusgraph-users and to our Discord channels to ask users for their opinion. If most users support the migration, then I’d say that we go ahead with it.
Another aspect of this we might want to discuss is whether we want to create our own Discord server or whether we just want to have a channel on the TinkerPop server which would probably also be an option. The TinkerPop server would have the advantage that JanusGraph questions are often actually Gremlin questions and discussions about TinkerPop are usually also interesting for JanusGraph. On the other hand, we might want to stay independent, and we probably also want to be able to create multiple channels (like for dev discussions or backend specific ones). I think I’m more in favour of a dedicated JanusGraph server, but I still wanted to mention both possibilities in case others see it differently.
Von: janusgraph-dev@... <janusgraph-dev@...> Im Auftrag von Boxuan Li
Vote for Discord.
Many questions on Gitter are not getting answered likely due to its lack of popularity. I personally haven’t been using Gitter for a long time because I don’t use it for any purpose other than answering JanusGraph related questions. Personally, migrating to Discord means I would be more able to help users.
One only benefit I like about Gitter is that it is indexed by Google.
|
|
|
|
Re: [DISCUSS] Discord Server
Boxuan Li
Vote for Discord.
toggle quoted message
Show quoted text
Many questions on Gitter are not getting answered likely due to its lack of popularity. I personally haven’t been using Gitter for a long time because I don’t use it for any purpose other than answering JanusGraph related questions. Personally, migrating to Discord means I would be more able to help users. One only benefit I like about Gitter is that it is indexed by Google.
|
|
|
|
[DISCUSS] Discord Server
Florian Hockmann
Hi,
we’re currently using Gitter as our chat system where we have two chat rooms, one mostly for users to ask questions and one to discuss development issues.
We already discussed moving to a different chat system two years ago as part of a discussion about creating the janusgraph-dev channel where Slack and Discord were mentioned as possible alternatives to Gitter [1]. This discussion about moving to a different chat system didn’t lead to a consensus so we stayed on Gitter. However, in the meantime TinkerPop has started a Discord server [2] which is getting more and more popular (~400 registered users right now, compared to ~250 in January). I’ve also recently noticed more and more JanusGraph questions being asked there so I wanted to bring this topic back up and suggest that we migrate to Discord.
Here are some advantages I see in favour of Discord:
A downside of Discord is of course that people need to create an account for it whereas a GitHub/Gitlab/Twitter account is enough for Gitter.
Any thoughts on this?
* I don’t have numbers to back this up, but Jan mentioned it already in the discussion two years ago and Discord itself lists a few big OSS communities [3].
[1]: https://groups.google.com/g/janusgraph-dev/c/5Fp2tQNn_Po/m/WdmLRf3WAgAJ |
|
|
|
[ANNOUNCE] JanusGraph 0.6.1 Release
The JanusGraph Technical Steering Committee is excited to announce the release of JanusGraph 0.6.1.
JanusGraph is an Apache TinkerPop enabled property graph database with support for a variety of storage and indexing backends. Thank you to all of the contributors. The release artifacts can be found at this location:
https://github.com/JanusGraph/janusgraph/releases/tag/v0.6.1 A full binary distribution is provided for user convenience: https://github.com/JanusGraph/janusgraph/releases/download/v0.6.1/janusgraph-full-0.6.1.zip A truncated binary distribution is provided:
https://github.com/JanusGraph/janusgraph/releases/download/v0.6.1/janusgraph-0.6.1.zip The online docs can be found here: https://docs.janusgraph.org To view the resolved issues and commits check the milestone here:
https://github.com/JanusGraph/janusgraph/milestone/22?closed=1Thank you very much,
Oleksandr Porunov |
|
|
|
[RESULT][VOTE] JanusGraph 0.6.1 release
This vote is now closed with a total of 3 +1s, no +0s and no -1s. The results are:
BINDING VOTES: +1 (3 -- Oleksandr Porunov, Florian Hockmann, Jan Jansen) 0 (0) -1 (0) NON-BINDING VOTES: +1 (0) 0 (0) -1 (0) Thank you very much, Oleksandr Porunov |
|
|
|
Re: [VOTE] JanusGraph 0.6.1 release
Jansen, Jan
I tested the docker image build works fine. Von: janusgraph-dev@... <janusgraph-dev@...> im Auftrag von Florian Hockmann <fh@...>
Gesendet: Mittwoch, 19. Januar 2022 14:43:26 An: janusgraph-dev@... Betreff: Re: [janusgraph-dev] [VOTE] JanusGraph 0.6.1 release I just performed a basic smoke test of both distribution archives, and everything worked as expected.
Great to see the first release based on the new release automation happening 😊
VOTE +1
Von: janusgraph-dev@... <janusgraph-dev@...>
Im Auftrag von Oleksandr Porunov
Hello,
A truncated binary distribution is provided:
The GPG key used to sign the release artifacts is available at: |
|
|
|
Re: [VOTE] JanusGraph 0.6.1 release
Florian Hockmann
I just performed a basic smoke test of both distribution archives, and everything worked as expected.
Great to see the first release based on the new release automation happening 😊
VOTE +1
Von: janusgraph-dev@... <janusgraph-dev@...> Im Auftrag von Oleksandr Porunov
Hello,
A truncated binary distribution is provided:
The GPG key used to sign the release artifacts is available at: |
|
|
|
[VOTE] JanusGraph 0.6.1 release
Hello,
We are happy to announce that JanusGraph 0.6.1 is ready for release. The release artifacts can be found at this location: https://github.com/JanusGraph/janusgraph/releases/tag/v0.6.1 A full binary distribution is provided for user convenience: https://github.com/JanusGraph/janusgraph/releases/download/v0.6.1/janusgraph-full-0.6.1.zip A truncated binary distribution is provided:
https://github.com/JanusGraph/janusgraph/releases/download/v0.6.1/janusgraph-0.6.1.zip https://github.com/JanusGraph/janusgraph/blob/v0.6/KEYS The docs can be found here: https://github.com/JanusGraph/janusgraph/releases/download/v0.6.1/janusgraph-0.6.1-doc.zip The release tag in Git can be found here: https://github.com/JanusGraph/janusgraph/tree/v0.6.1 The release notes are available here: https://github.com/JanusGraph/janusgraph/blob/v0.6/docs/changelog.md#version-061-release-date-january-18-2022 This [VOTE] will open for the next 3 days --- closing Saturday, January 22, 2022 at 2:55 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.1 release
The PR for automatic releases is here: https://github.com/JanusGraph/janusgraph/pull/2941
Best regards, Oleksandr |
|
|
|
JG Schema - addConnection seem to create duplicate connections
Peter Molnar
Hi All,
I have a strange behaviour while using the addConnection method for creating JG schema constraints. It seems it creates duplicated connections in some cases. Please see below how to reproduce this with JG v0.6 and Cassandra v3.11.11 backend. I just used the below snippets in Gremlin Console 3.5.1 to connect to JG remotely. The graph is supposed model transactions and parties involved in the transaction. It has transaction, person and entity nodes. A transaction is supposed to have one "from party" (either person or entity) connected with FROM edge and one "to party" (either person or entity) connected with TO edge. For example (Person A) --FROM--> (Transaction #1) --TO--> (Entity A) for expressing that "Transaction #1" was performed between "Person A" and "Entity A" and the source of the transaction was "Person A". Creating dynamic graph and schema ------- map = new HashMap();
map.put("storage.backend","cql");
map.put("storage.hostname","cassandra");
map.put("query.force-index", "false");
map.put("schema.default", "default");
map.put("schema.constraints", "false");
map.put("graph.graphname", "transactionGraph")
ConfiguredGraphFactory.createConfiguration(new MapConfiguration(map));
graph = ConfiguredGraphFactory.open("transactionGraph");
mgmt = graph.openManagement();
transaction = mgmt.makeVertexLabel('transaction').make();
person = mgmt.makeVertexLabel('person').make();
entity = mgmt.makeVertexLabel('entity').make();
fromEdge = mgmt.makeEdgeLabel('FROM').multiplicity(ONE2ONE).make()
mgmt.addConnection(fromEdge, person, transaction)
mgmt.addConnection(fromEdge, entity, transaction)
toEdge = mgmt.makeEdgeLabel('TO').multiplicity(ONE2ONE).make()
mgmt.addConnection(toEdge, transaction, person)
mgmt.addConnection(toEdge, transaction, entity)
mgmt.commit()
Checking connections of the schema ---------------- mgmt = graph.openManagement()
edges = mgmt.getRelationTypes(EdgeLabel.class)
fromEdge = edges[0]
toEdge = edges[1]
fromEdge.mappedConnections().size() // as I would expect, it has two connections
toEdge.mappedConnections().size() // why 4 connections are here? I would expect only two connections similarly to the FROM edge
mgmt.close() -------------- Could you please have a look and let me know if this is a feature or a bug? Thanks, Peter |
|
|
|
Re: [DISCUSS] JanusGraph 0.6.1 release
Hi Florian,
It will definitely help me to try some parts of automation for 0.6.1 release. I will work on it today's evening and tomorrow. If I bump into the problem and can't start a release till Monday (January 17), please, go ahead with the release without waiting for me. Best regards, Oleksandr |
|
|
|
Re: [DISCUSS] JanusGraph 0.6.1 release
Florian Hockmann
Hi Oleksandr,
automating the release process or at least parts of it would definitely be great!
Right now, we have all issues and PRs closed that are linked to the milestone for 0.6.1 so we could in general proceed with the release process, but I think it wouldn’t be a big problem if we’d delay the release a bit so we could already use an automated release process.
Do you think that it makes sense to wait with the 0.6.1 release for this? Would it maybe even help if you could try out some of the automation directly during the release process? Or would this delay the release too much?
Von: janusgraph-dev@... <janusgraph-dev@...> Im Auftrag von Oleksandr Porunov
Hi, |
|
|
|
Re: [DISCUSS] JanusGraph 0.6.1 release
Hi,
I'm in favor of releasing 0.6.1 version. That said, it would make sense to automate the releasing process as Jan mentioned. I'm planning to try to work on automation or partial automation this week. The main reason for that is to have deterministic way of making those builds. At this moment when we are creating `jar`s which we are publishing everywhere - we are creating it locally on a release manager's computer with their own `java` installation. Yes, the release manager signs every resource but we have no idea what version of Java was used to create this build. In theory if the release manager have vulnerable machine it could lead to infecting that `jar` with malicious code. I think, it would be better to make all the builds in GH actions and use only them for release artifacts. I will try to work on that this week but I'm good if you release 0.6.1 using the current release process. Just use openjdk 1.8.<latest> for the release. Best regards, Oleksandr |
|
|
|
Re: [DISCUSS] JanusGraph 0.6.1 release
Jansen, Jan
Hi
Von: janusgraph-dev@... <janusgraph-dev@...> im Auftrag von Florian Hockmann <fh@...>
Gesendet: Mittwoch, 5. Januar 2022 11:38:48 An: janusgraph-dev@... Betreff: Re: [janusgraph-dev] [DISCUSS] JanusGraph 0.6.1 release Given that there haven’t been any responses, I assume that there are no major objections to releasing 0.6.1 soon but that there is also no high interest in getting it out as a hotfix release as soon as possible (which is OK in my opinion given that probably not many users are using the janusgraph.sh script to start JG+Cassandra+ES all at once). So, I suggest that we just treat it as a normal maintenance release that will also contain the workaround for the Log4j CVE in ES among other fixes.
Are there any open issues / PRs that you think should be included in 0.6.1?
PR #2899 is already linked to the milestone v0.6.1 and it fixes a NullPointerException so I’d at least wait for that PR to be merged for 0.6.1: https://github.com/JanusGraph/janusgraph/pull/2899
Does anyone want to volunteer to be release manager for this release? Otherwise, I can also do it.
Von: janusgraph-dev@... <janusgraph-dev@...>
Im Auftrag von Florian Hockmann
Hi,
we wanted to release patch versions shortly given the CVE in Log4j to mitigate it in the Elasticsearch version we distribute with the pre-packaged distribution: https://lists.lfaidata.foundation/g/janusgraph-dev/message/1554
I just merged a PR to the v0.6 branch with a simple mitigation: https://github.com/JanusGraph/janusgraph/pull/2892
As I explained in a comment in that PR, the mitigation now only landed in v0.6 and not in v0.5 as we don’t have any continuous integration for that branch and in general, I’m not sure it’s worth the effort to release a patch release for that branch, given that it only helps users who start JanusGraph together with ES from the `bin/janusgraph.sh` script.
So, we could release 0.6.1 now with the simple mitigation for ES. But if we want to release soon, then the release date would be in the middle of the holiday season. That would at least open the question whether someone is available over the holiday period to handle the release. Since I will not be available myself, I personally suggest that we postpone the release to the beginning of January. If, however someone is willing to act as release manager during the holiday period, then we can still do the release soon. We would of course also need at least 3 TSC members for the VOTE, but I guess that should be possible if we could start the VOTE already in the beginning of next week.
Apart from the release date and who will be the release manager, are there any important issues still open that really need to be fixed for 0.6.1? I think we should try to release 0.6.1 as soon as possible so new users don’t start with a vulnerable Elasticsearch installation and we can release 0.6.2 soon after, if necessary, but if you see any issues that we should really include, then we can discuss that of course.
Other questions that we could discuss for this release:
Best regards, Florian
[2]: https://github.com/JanusGraph/janusgraph/pull/2892#issuecomment-993536460 |
|
|
|
Re: [DISCUSS] JanusGraph 0.6.1 release
Florian Hockmann
Given that there haven’t been any responses, I assume that there are no major objections to releasing 0.6.1 soon but that there is also no high interest in getting it out as a hotfix release as soon as possible (which is OK in my opinion given that probably not many users are using the janusgraph.sh script to start JG+Cassandra+ES all at once). So, I suggest that we just treat it as a normal maintenance release that will also contain the workaround for the Log4j CVE in ES among other fixes.
Are there any open issues / PRs that you think should be included in 0.6.1?
PR #2899 is already linked to the milestone v0.6.1 and it fixes a NullPointerException so I’d at least wait for that PR to be merged for 0.6.1: https://github.com/JanusGraph/janusgraph/pull/2899
Does anyone want to volunteer to be release manager for this release? Otherwise, I can also do it.
Von: janusgraph-dev@... <janusgraph-dev@...> Im Auftrag von Florian Hockmann
Hi,
we wanted to release patch versions shortly given the CVE in Log4j to mitigate it in the Elasticsearch version we distribute with the pre-packaged distribution: https://lists.lfaidata.foundation/g/janusgraph-dev/message/1554
I just merged a PR to the v0.6 branch with a simple mitigation: https://github.com/JanusGraph/janusgraph/pull/2892
As I explained in a comment in that PR, the mitigation now only landed in v0.6 and not in v0.5 as we don’t have any continuous integration for that branch and in general, I’m not sure it’s worth the effort to release a patch release for that branch, given that it only helps users who start JanusGraph together with ES from the `bin/janusgraph.sh` script.
So, we could release 0.6.1 now with the simple mitigation for ES. But if we want to release soon, then the release date would be in the middle of the holiday season. That would at least open the question whether someone is available over the holiday period to handle the release. Since I will not be available myself, I personally suggest that we postpone the release to the beginning of January. If, however someone is willing to act as release manager during the holiday period, then we can still do the release soon. We would of course also need at least 3 TSC members for the VOTE, but I guess that should be possible if we could start the VOTE already in the beginning of next week.
Apart from the release date and who will be the release manager, are there any important issues still open that really need to be fixed for 0.6.1? I think we should try to release 0.6.1 as soon as possible so new users don’t start with a vulnerable Elasticsearch installation and we can release 0.6.2 soon after, if necessary, but if you see any issues that we should really include, then we can discuss that of course.
Other questions that we could discuss for this release:
Best regards, Florian
[2]: https://github.com/JanusGraph/janusgraph/pull/2892#issuecomment-993536460 |
|
|
|
[DISCUSS] JanusGraph 0.6.1 release
Florian Hockmann
Hi,
we wanted to release patch versions shortly given the CVE in Log4j to mitigate it in the Elasticsearch version we distribute with the pre-packaged distribution: https://lists.lfaidata.foundation/g/janusgraph-dev/message/1554
I just merged a PR to the v0.6 branch with a simple mitigation: https://github.com/JanusGraph/janusgraph/pull/2892
As I explained in a comment in that PR, the mitigation now only landed in v0.6 and not in v0.5 as we don’t have any continuous integration for that branch and in general, I’m not sure it’s worth the effort to release a patch release for that branch, given that it only helps users who start JanusGraph together with ES from the `bin/janusgraph.sh` script.
So, we could release 0.6.1 now with the simple mitigation for ES. But if we want to release soon, then the release date would be in the middle of the holiday season. That would at least open the question whether someone is available over the holiday period to handle the release. Since I will not be available myself, I personally suggest that we postpone the release to the beginning of January. If, however someone is willing to act as release manager during the holiday period, then we can still do the release soon. We would of course also need at least 3 TSC members for the VOTE, but I guess that should be possible if we could start the VOTE already in the beginning of next week.
Apart from the release date and who will be the release manager, are there any important issues still open that really need to be fixed for 0.6.1? I think we should try to release 0.6.1 as soon as possible so new users don’t start with a vulnerable Elasticsearch installation and we can release 0.6.2 soon after, if necessary, but if you see any issues that we should really include, then we can discuss that of course.
Other questions that we could discuss for this release:
Best regards, Florian
[2]: https://github.com/JanusGraph/janusgraph/pull/2892#issuecomment-993536460 |
|
|
|
JanusGraph and Apache Log4J CVE-2021-44228 (aka "log4shell")
Florian Hockmann
A critical security vulnerability was reported in Apache Log4j 2 on December 9, 2021: CVE-2021-44228 [1]. JanusGraph itself is not directly affected by this vulnerability as it still uses log4j 1.2 and the CVE only affects log4j2.
However, the two index backends Elasticsearch and Apache Solr are affected by the CVE. Both projects have already published reports on how they are affected and how the vulnerability can be mitigated:
Apache HBase, Apache TinkerPop, Apache Spark, and Apache Hadoop are all also still on log4j 1 and are therefore also not affected.
We recommend all JanusGraph users who use JanusGraph together with Elasticsearch or Apache Solr to follow the recommendations listed in the reports linked above. This mostly comes down to updating the backends once an update with a fix is available and to set the JVM option
We also plan to release patch versions for 0.5 and 0.6 shortly for the Elasticsearch version that is distributed as part of the pre-packed (“full”) distribution of JanusGraph to adopt these recommendations by default for users who start JanusGraph via the `bin/janusgraph.sh` script which also starts Elasticsearch.
Given that Log4j 1 already reached EOL (end of life) and is also affected by other CVEs, we also plan to move away from that version in a future release of JanusGraph.
Best regards, The JanusGraph Technical Steering Committee
|
|
|