Date   

Re: [DISCUSS] 1.0.0 / 0.6.3 Releases

Oleksandr Porunov
 

Yes, I like that idea. Let's publish rc1 sooner and release `1.0.0` or `0.7.0` in January depending on what we decide.

As for snapshot releases I will go ahead and prepare some PR and we can discuss it there or in the linked thread.


Re: [DISCUSSION] Release snapshot versions on each commit

Florian Hockmann
 

Thanks for bumping this thread again in the discussion for the 1.0.0 release, Oleksandr!

 

> Basically, I think it's possible to configure different publishing flows (either to sonatype for official releases or to GitHub Packages for unofficial releases).

 

+1 on GitHub Packages for snapshots on each commit and sonatype for official releases.

 

As a possible next step for the future, we could maybe also build a Docker image for each commit (or daily if it’s difficult to trigger a build in janusgraph-docker from each commit in the main repo) and publish that somewhere (not sure if Docker Hub or also a different repo for these non-release based images).

 

> Moreover, about the link which you shared. Did we document it anywhere? If no, I think it would be good to create a separate documentation page which tells about release artifacts for each commit and potentially releases to GitHub Packages for each commit. 

 

No, that is not documented any where that I know of. I at least searched for these artifacts recently but couldn’t find them. Documenting this would be great, especially of course if we also publish Maven snapshot packages to make them easier to consume.

 

One general note: I would usually just assume lazy consensus for such discussions where you don’t get many responses and especially no negative response. People here simply might not have the time to respond, but that doesn’t mean that they don’t like the idea. I remember that I’ve read this thread, liked the idea, but didn’t have much to add to the discussion so I didn’t respond. Such a behaviour shouldn’t stop good ideas from being implemented 😉

 

Von: janusgraph-dev@... <janusgraph-dev@...> Im Auftrag von Oleksandr Porunov
Gesendet: Mittwoch, 25. August 2021 14:31
An: janusgraph-dev@...
Betreff: Re: [janusgraph-dev] [DISCUSSION] Release snapshot versions on each commit

 

Hi Jan,

Thanks for pointing on that! That indeed uploads distribution for a commit but it doesn't provide you with the maven nexus repository to use those distributions. Basically, it means, that you will need to physically download `distribution-builds` and run it. In case you would like to run JanusGraph embedded into the application, it becomes not as easy to be used due to necessity to include transitive dependencies manually.
What I mean is to publish staging artifacts to the maven repository such as GitHub actions. If so, people could just include latest JanusGraph master snapshot releases simply defining something like:

<dependency>

  <groupId>org.janusgraph</groupId>

  <artifactId>janusgraph-core</artifactId>

  <version>0.6.0-SNAPSHOT-12345</version>

</dependency>


Ignore `version` as for now because I didn't think about versioning yet but you can see a simple example here: https://github.com/orgs/mapped/packages?repo_name=janusgraph
See the commit here: https://github.com/mapped/janusgraph/commit/a94a0c03cb9d1b1445901c6735aff3e66b8692ac

Basically, I think it's possible to configure different publishing flows (either to sonatype for official releases or to GitHub Packages for unofficial releases).

Moreover, about the link which you shared. Did we document it anywhere? If no, I think it would be good to create a separate documentation page which tells about release artifacts for each commit and potentially releases to GitHub Packages for each commit.  

Best regards,
Oleksandr


Re: [DISCUSS] 1.0.0 / 0.6.3 Releases

Florian Hockmann
 

My intention here is that we try to release from master soon-ish, like in January ideally. We have features on master that were implemented about a year ago already and some dependency updates that include fixes for security vulnerabilities. These security vulnerabilities alone are something that users frequently ask about to get an update for.

 

Having said that, I’m completely fine with saying that we want certain features definitely in 1.0.0, like support for ES 8 or the improvements to our indexing that Florian is working on. If we however expect those things to take longer to complete, then I’d suggest that we instead release 0.7.0 first.

 

It’s of course not easy to predict when ES 8.6.0 will be released or when other features are in place which makes it hard to decide now how we want to proceed. But since we have already decided to first publish a release candidate for 1.0.0 and therefore have to wait until January for proper feedback and because of the holiday season, I’d say we try to aim for a release date of 1.0.0 in January. We can then come back to this in January to see which features that we’d like to have in 1.0.0 are still not ready and then decide:

  1. Do we need to have these features in 1.0.0 or can we also release them later, like in 1.1.0?
  2. How much more time do we expect we need to implement them?

Based on this assessment, we can then decide in January whether we can release 1.0.0 already, want to postpone it a bit or whether it will take longer until we want to release 1.0.0 and we therefore could release 0.7.0 as an intermediate release to already get most of these features out in a stable release.

 

How does that sound?

 

Regarding snapshots I will respond directly in that thread you’ve linked. I think however that release candidates still make sense irrespective of snapshots as some users might want to try out a release candidate and provide feedback on that, but don’t want to use snapshot builds. Similarly to how you described it for a final release where we simply signal stability, we also signal some kind of stability for a release candidate, even if it’s much less than for a final release.

 

 

Von: janusgraph-dev@... <janusgraph-dev@...> Im Auftrag von Oleksandr Porunov
Gesendet: Mittwoch, 30. November 2022 17:38
An: janusgraph-dev@...
Betreff: Re: [janusgraph-dev] [DISCUSS] 1.0.0 / 0.6.3 Releases

 

You are right that these breaking changes regarding ElasticSearch side will be affecting only those users who want to switch using ElasticSearch 8. Users On ElasticSearch 6 and 7 won't be affected.
That said, for such a major upgrade I think it makes sense to include ES 8 support in JanusGraph 1.0.0 because I expect many people will want to switch to the newer ES version. Moreover, it looks like there is only one PR left targeted ElasticSearch 8.6.0 release ( 
https://github.com/elastic/elasticsearch/pulls?q=is%3Apr+is%3Aopen+label%3Av8.6.0 ). So, I would expect ES 8.6.0 coming soon but can't guarantee that because I don't know their deadline. I would suggest to include ES 8 support if ES 8.6.0 is released anytime in the next 2-3 weeks. Otherwise we can retarget this upgrade to later versions of JanusGraph.

Notice, we have some issues targeting `1.0.0` release: 
https://github.com/JanusGraph/janusgraph/milestones/Release%20v1.0.0 
I don't think we will be able to complete all of them till the release but I guess some of them might be better to be included into the release.
Florian Grieskamp currently works on some features which may be a breaking change for all users but those features are quite good I think.
Cost based index selection: 
https://github.com/JanusGraph/janusgraph/pull/3246 
He is also working on re-engineering index management life-cycle which might be a breaking change as well (see issue:
https://github.com/JanusGraph/janusgraph/issues/857) (see his branch: https://github.com/JanusGraph/janusgraph/compare/master...rngcntr:janusgraph:new-index-management).
I don't know if he plans to complete those issues anytime soon, but if he does then those contributions would be very suitable for the major release like `1.0.0`.

Regarding rc releases - I'm totally fine doing rc1, rc2, rcX. That said, I would suggest to maybe take a look at the following discussion again: 
https://lists.lfaidata.foundation/g/janusgraph-dev/topic/discussion_release_snapshot/84922650 
I still have some feeling that making snapshot (or whatever we call it) releases per each commit would make sense. Users will have an easy way to use all the latest JanusGraph features without waiting for official (fully tested) releases. 
With such approach I feel that official releases will be just an indicator to users that we tested the new added functionality which was added after the previous official release and we don't expect to break that functionality anytime soon.
Adding publishing to GitHub is quite easy (see an example:
https://github.com/mapped/janusgraph/commit/a94a0c03cb9d1b1445901c6735aff3e66b8692ac ) but I think we could do that for sonatype as well if we think we need snapshots there.


Re: [DISCUSS] 1.0.0 / 0.6.3 Releases

Oleksandr Porunov
 

You are right that these breaking changes regarding ElasticSearch side will be affecting only those users who want to switch using ElasticSearch 8. Users On ElasticSearch 6 and 7 won't be affected.
That said, for such a major upgrade I think it makes sense to include ES 8 support in JanusGraph 1.0.0 because I expect many people will want to switch to the newer ES version. Moreover, it looks like there is only one PR left targeted ElasticSearch 8.6.0 release ( https://github.com/elastic/elasticsearch/pulls?q=is%3Apr+is%3Aopen+label%3Av8.6.0 ). So, I would expect ES 8.6.0 coming soon but can't guarantee that because I don't know their deadline. I would suggest to include ES 8 support if ES 8.6.0 is released anytime in the next 2-3 weeks. Otherwise we can retarget this upgrade to later versions of JanusGraph.

Notice, we have some issues targeting `1.0.0` release: https://github.com/JanusGraph/janusgraph/milestones/Release%20v1.0.0 
I don't think we will be able to complete all of them till the release but I guess some of them might be better to be included into the release.
Florian Grieskamp currently works on some features which may be a breaking change for all users but those features are quite good I think.
Cost based index selection: https://github.com/JanusGraph/janusgraph/pull/3246 
He is also working on re-engineering index management life-cycle which might be a breaking change as well (see issue: https://github.com/JanusGraph/janusgraph/issues/857) (see his branch: https://github.com/JanusGraph/janusgraph/compare/master...rngcntr:janusgraph:new-index-management).
I don't know if he plans to complete those issues anytime soon, but if he does then those contributions would be very suitable for the major release like `1.0.0`.

Regarding rc releases - I'm totally fine doing rc1, rc2, rcX. That said, I would suggest to maybe take a look at the following discussion again: https://lists.lfaidata.foundation/g/janusgraph-dev/topic/discussion_release_snapshot/84922650 
I still have some feeling that making snapshot (or whatever we call it) releases per each commit would make sense. Users will have an easy way to use all the latest JanusGraph features without waiting for official (fully tested) releases. 
With such approach I feel that official releases will be just an indicator to users that we tested the new added functionality which was added after the previous official release and we don't expect to break that functionality anytime soon.
Adding publishing to GitHub is quite easy (see an example: https://github.com/mapped/janusgraph/commit/a94a0c03cb9d1b1445901c6735aff3e66b8692ac ) but I think we could do that for sonatype as well if we think we need snapshots there.


Re: [DISCUSS] 1.0.0 / 0.6.3 Releases

Florian Hockmann
 

Elasticsearch 8 is of course a good point. But do we need to support that directly in 1.0.0? Elasticsearch 7.17 seems to be still supported roughly until 9.0.0 gets released if I understood their EoL policy correctly [1].

Can’t we also add support for Elasticsearch 8 in a minor update, like 1.1.0 and clearly document how people need to migrate their indices if they want to update their Elasticsearch installation to v8? What I mean is that it’s only a breaking change for users who actually update to Elasticsearch 8 and then they should expect some breaking changes in general.

 

Or do you expect the change on our side to already be breaking so that all users have to migrate their indices, even if they stay on ES 7?

 

In general, I think we will end up with a release date for 1.0.0 some time in January irrespective of this if we want to publish a release candidate first and then provide users some time to try it out and provide feedback. (And nobody argued against it, so I already went ahead and created a PR for the release candidate.)

 

[1]: https://www.elastic.co/support/eol

 

Von: janusgraph-dev@... <janusgraph-dev@...> Im Auftrag von Oleksandr Porunov
Gesendet: Dienstag, 29. November 2022 17:11
An: janusgraph-dev@...
Betreff: Re: [janusgraph-dev] [DISCUSS] 1.0.0 / 0.6.3 Releases

 

Hi,

Upgrade to ElasticSearch 8 will be a breaking change in regarding to Geoshape properties because we won't have Prefix Tree indexing strategy anymore. Users will need to do migration of any indexes containing Geoshape properties because Circle shape isn't compatible with the BDB indexing strategy (the only geoshape indexing strategy available in ES 8). See: https://github.com/JanusGraph/janusgraph/pull/3268
That PR is blocked until ElasticSearch 8.6.0 is released. I would prefer including such a breaking change into the 1.0.0 release.

In December there are usually many holidays and I suspect not many people will work during holidays. I think it would make sense to make `1.0.0` release early January, so that we have time to finish several other PRs and allow more people to test it because it will include quite a few breaking changes.

Best regards,
Oleksandr


Re: [DISCUSS] 1.0.0 / 0.6.3 Releases

Oleksandr Porunov
 

Hi,

Upgrade to ElasticSearch 8 will be a breaking change in regarding to Geoshape properties because we won't have Prefix Tree indexing strategy anymore. Users will need to do migration of any indexes containing Geoshape properties because Circle shape isn't compatible with the BDB indexing strategy (the only geoshape indexing strategy available in ES 8). See: https://github.com/JanusGraph/janusgraph/pull/3268
That PR is blocked until ElasticSearch 8.6.0 is released. I would prefer including such a breaking change into the 1.0.0 release.

In December there are usually many holidays and I suspect not many people will work during holidays. I think it would make sense to make `1.0.0` release early January, so that we have time to finish several other PRs and allow more people to test it because it will include quite a few breaking changes.

Best regards,
Oleksandr


Re: [DISCUSS] 1.0.0 / 0.6.3 Releases

Florian Hockmann
 

Yes, a release candidate probably makes sense for the 1.0.0 release. I think we don’t need a formal voting process for a release candidate. So, if there are no objections, I start preparing such a release candidate which will also include a PR to update the version numbers on master.

 

If there are any issues that you think should be included in the release candidate, then please list them. Otherwise, simply everything that is merged into master until the PR that updates the version numbers is merged will be included.

 

Von: janusgraph-dev@... <janusgraph-dev@...> Im Auftrag von Boxuan Li
Gesendet: Montag, 28. November 2022 17:39
An: janusgraph-dev@...
Betreff: Re: [janusgraph-dev] [DISCUSS] 1.0.0 / 0.6.3 Releases

 

That sounds really awesome! Just one thought:

 

Shall we do a RC release (e.g. 1.0.0 RC1) before the official 1.0.0 release? There are quite some breaking and major changes in 1.0.0, and I feel we should be extra cautious about that.

 

Cheers,

Boxuan


From: janusgraph-dev@... <janusgraph-dev@...> on behalf of Florian Hockmann via lists.lfaidata.foundation <fh=florian-hockmann.de@...>
Sent: Monday, November 28, 2022 10:42:31 AM
To:
janusgraph-dev@... <janusgraph-dev@...>
Subject: [janusgraph-dev] [DISCUSS] 1.0.0 / 0.6.3 Releases

 

Hi,

 

I would like to start a discussion about our next release(s) as there were multiple requests from the community already.

Our last release (0.6.2) was also already half a year ago (May 31) and our latest major release (0.6.0) was over a year ago in September 2021.

 

We also already have quite some features ready for 1.0.0 (and I probably even forgot some other important ones):

 

I think these are really substantial improvements that we should release to our users and therefore at least not wait much longer for a major release. Users have also repeatedly asked for a release that contains some of these improvements, especially the security related dependency updates.

 

So, are there any important issues / PRs that you definitely want to see included in the next release? Otherwise, I suggest that we set a fixed deadline of when we start the release process and everything that is not merged until then will be moved to a follow-up release.

 

Are there any issues that should definitely be included in a 1.0.0 release but will not be finished in the next few weeks? I think in that case we could also decide to release 0.7.0 first from master so we don’t block the release just because we have decided that the next major release should be 1.0.0.

But I think it should also not be a problem to postpone any open issues to a later major release. As Oleksandr mentioned in the thread where we decided that 1.0.0 should be next major release, 1.0.0 only indicates that JanusGraph is ready for production usage [1]. It doesn’t mean that there won’t be breaking changes afterwards (as there definitely will be).

 

Together with 1.0.0 (or 0.7.0 if we decide on that as the next major release), we can also release 0.6.3 from the 0.6 branch. If you see any issues that should be included in that release, then that would of course also be good to know.

 

Does anyone want to volunteer being the release manager for these two releases? Otherwise, I can also do it.

 

Regards,

Florian

 

[1]: https://lists.lfaidata.foundation/g/janusgraph-dev/message/1517


Re: [DISCUSS] 1.0.0 / 0.6.3 Releases

Boxuan Li
 

That sounds really awesome! Just one thought:

Shall we do a RC release (e.g. 1.0.0 RC1) before the official 1.0.0 release? There are quite some breaking and major changes in 1.0.0, and I feel we should be extra cautious about that.

Cheers,
Boxuan

From: janusgraph-dev@... <janusgraph-dev@...> on behalf of Florian Hockmann via lists.lfaidata.foundation <fh=florian-hockmann.de@...>
Sent: Monday, November 28, 2022 10:42:31 AM
To: janusgraph-dev@... <janusgraph-dev@...>
Subject: [janusgraph-dev] [DISCUSS] 1.0.0 / 0.6.3 Releases
 

Hi,

 

I would like to start a discussion about our next release(s) as there were multiple requests from the community already.

Our last release (0.6.2) was also already half a year ago (May 31) and our latest major release (0.6.0) was over a year ago in September 2021.

 

We also already have quite some features ready for 1.0.0 (and I probably even forgot some other important ones):

 

I think these are really substantial improvements that we should release to our users and therefore at least not wait much longer for a major release. Users have also repeatedly asked for a release that contains some of these improvements, especially the security related dependency updates.

 

So, are there any important issues / PRs that you definitely want to see included in the next release? Otherwise, I suggest that we set a fixed deadline of when we start the release process and everything that is not merged until then will be moved to a follow-up release.

 

Are there any issues that should definitely be included in a 1.0.0 release but will not be finished in the next few weeks? I think in that case we could also decide to release 0.7.0 first from master so we don’t block the release just because we have decided that the next major release should be 1.0.0.

But I think it should also not be a problem to postpone any open issues to a later major release. As Oleksandr mentioned in the thread where we decided that 1.0.0 should be next major release, 1.0.0 only indicates that JanusGraph is ready for production usage [1]. It doesn’t mean that there won’t be breaking changes afterwards (as there definitely will be).

 

Together with 1.0.0 (or 0.7.0 if we decide on that as the next major release), we can also release 0.6.3 from the 0.6 branch. If you see any issues that should be included in that release, then that would of course also be good to know.

 

Does anyone want to volunteer being the release manager for these two releases? Otherwise, I can also do it.

 

Regards,

Florian

 

[1]: https://lists.lfaidata.foundation/g/janusgraph-dev/message/1517


Re: [DISCUSS] 1.0.0 / 0.6.3 Releases

Florian Hockmann
 

Hi Dustin,

 

sure, that will be included. I should have mentioned that probably:

 

0.6.3 will include all issues / PRs tagged with the 0.6.3 milestone:

https://github.com/JanusGraph/janusgraph/milestone/24

 

1.0.0 will include everything from the 0.6.3 milestone, and additionally everything from the 1.0.0 milestone:

https://github.com/JanusGraph/janusgraph/milestone/21

 

The PR you linked is included in the 1.0.0 milestone.

 

Von: janusgraph-dev@... <janusgraph-dev@...> Im Auftrag von dustinwaguespack@...
Gesendet: Montag, 28. November 2022 16:58
An: janusgraph-dev@...
Betreff: Re: [janusgraph-dev] [DISCUSS] 1.0.0 / 0.6.3 Releases

 

Hi Florian,

Would this release contain the commits in this PR - https://github.com/JanusGraph/janusgraph/pull/2904?

v/r
Dustin


Re: [DISCUSS] 1.0.0 / 0.6.3 Releases

dustinwaguespack@...
 

Hi Florian,

Would this release contain the commits in this PR - https://github.com/JanusGraph/janusgraph/pull/2904?

v/r
Dustin


[DISCUSS] 1.0.0 / 0.6.3 Releases

Florian Hockmann
 

Hi,

 

I would like to start a discussion about our next release(s) as there were multiple requests from the community already.

Our last release (0.6.2) was also already half a year ago (May 31) and our latest major release (0.6.0) was over a year ago in September 2021.

 

We also already have quite some features ready for 1.0.0 (and I probably even forgot some other important ones):

 

I think these are really substantial improvements that we should release to our users and therefore at least not wait much longer for a major release. Users have also repeatedly asked for a release that contains some of these improvements, especially the security related dependency updates.

 

So, are there any important issues / PRs that you definitely want to see included in the next release? Otherwise, I suggest that we set a fixed deadline of when we start the release process and everything that is not merged until then will be moved to a follow-up release.

 

Are there any issues that should definitely be included in a 1.0.0 release but will not be finished in the next few weeks? I think in that case we could also decide to release 0.7.0 first from master so we don’t block the release just because we have decided that the next major release should be 1.0.0.

But I think it should also not be a problem to postpone any open issues to a later major release. As Oleksandr mentioned in the thread where we decided that 1.0.0 should be next major release, 1.0.0 only indicates that JanusGraph is ready for production usage [1]. It doesn’t mean that there won’t be breaking changes afterwards (as there definitely will be).

 

Together with 1.0.0 (or 0.7.0 if we decide on that as the next major release), we can also release 0.6.3 from the 0.6 branch. If you see any issues that should be included in that release, then that would of course also be good to know.

 

Does anyone want to volunteer being the release manager for these two releases? Otherwise, I can also do it.

 

Regards,

Florian

 

[1]: https://lists.lfaidata.foundation/g/janusgraph-dev/message/1517


Re: [DISCUSSION] JanusGraph db-cache in distributed environment

Boxuan Li
 

Thanks for starting this thread! Just want to mention there is an open PR for Redis cache integration: https://github.com/JanusGraph/janusgraph/pull/3100


[DISCUSSION] JanusGraph db-cache in distributed environment

Oleksandr Porunov
 

Hello,

I would like to start a topic about JanusGraph db-cache we have today and ways to improve it for distributed environments.
I want to split this topic on several issues I see with this cache:
1) Invalidation
2) Performance
3) Sharding

Invalidation

The first main issue with this cache is that it doesn't have good invalidation mechanisms.
As for now there are 3 invalidation mechanisms:
  1. Enough time passed (cache.db-cache-time).
  2. Evicted due to cache size limitation (cache.db-cache-time).
  3. Evicted on current JanusGraph instance only due to being mutated on the current JanusGraph instance.
I believe that we should give users a possibility to either somehow invalidate this cache when they deemed necessary (using their own strategy). Thus, I created the next PR to give users a simple possibility to invalidate cache manually: https://github.com/JanusGraph/janusgraph/pull/3184
Moreover, I think it would be great if there would be some kind of pattern implemented in JanusGraph to be able to invalidate data on mutation on all JanusGraph nodes ( the issue to track this feature is here: https://github.com/JanusGraph/janusgraph/issues/3155 ). I don't know how it's best to implement the later feature, but I have following ideas:
- We can reuse JanusGraph messaging mechanism (i.e. the one which works on top of a storage backend). With this feature users don't need any external messaging tools and can enable global db-cache invalidation on mutation easily. The downside is most likely performance, because usually those storage backends are not the best tools for messaging.
- Using external tool for messaging (let's say Kafka, Redis, etc.). The advantage would be performance most likely but the disadvantage is that the user now needs to manage a separate external system.
- Providing an interface for mutated data invalidation. We can make a general interface which accepts a set of keys which need to be evicted in db-cache and then the implementation can be either developed by the user themselves or they can use existing JanusGraph solutions (let.s say we will have 3 options at the beggining: `storage-messaging`, `redis-messaging`, `kafka-messaging` and we will be able to add more systems if there is interest in them).

That's just a brainstorming, so if anyone has any thoughts about it. please share. Maybe this issue should be solved differently and maybe I should look at it from a different angle.

Performance

For some reason we didn't look at this side too much but as noted here and here the Guava cache we use isn't the best option. I didn't investigate what is the best option for those caches we have (and we have 8 caches as commented here).
As an obvious solution is to move from Guava to Caffeine cache. That said, if anyone thinks we need to try another cache or have any thoughts about it, please post them here.

Sharding

As for now db-cache caches all the data per JanusGraph instance. No any cache data is shared between multiple JanusGraph instances. In some use-cases this is an advantage but in some situations it's a disadvantage.
I think that it would makes sense to add several options for different db-cache implementation. Some implementations would be local only and some distributed against all participating JanusGraph nodes.
The are several implementations I could think of:
1) Default local only db-cache. This cache would use Caffeine cache implementation and there could be some invalidation strategies available to trigger invalidation on all JanusGraph nodes using some messaging tools (as described in `Invalidation` section).
2) Redis cache - this cache would use external Redis nodes to cache all the data. The advantage is that Redis may be shared and scaled separately. All the data in Redis will be distributed (depending on installation) which may improve cache usage in some cases. Maybe also using client-side caching could improve performance in some cases.
3) Hazelcast cache - this cache would require additional configuration and making sure that all JanusGraph nodes can reach other JanusGraph nodes. Hazelcast cache can be bound to JVM but being able to form a cluster on nodes for the cache and shard / replicate all the data between all the nodes in the cluster. With this cache users won't need to manage external cache nodes but users will need to make sure that their JanusGraph installation has direct network access to all nodes in the cluster.

Any thoughts about any of the above points (or maybe missing points / issues) are very welcome.

Best regards,
Oleksandr


LF AI&Data JanusGraph Project License Scan and Findings August 2022

Jeff Shapiro <jshapiro@...>
 

Hi Team,

Here are the results from the August 2022 license scan of the JanusGraph project. The scan was performed using the Linux Foundation Fossology server. Licenses and copyrights were examined.

The key findings (if any) and license summary can be found in the HTML report, the list of files in the spreadsheet, and also find the SPDX file listed below:

REPORTS:

lfai/JanusGraph, code pulled 2022-08-08
- report: https://lfscanning.org/reports/lfai/JanusGraph-2022-08-08-128b378d-8656-4907-ad70-b876a161c82d.html
- xlsx: https://lfscanning.org/reports/lfai/JanusGraph-2022-08-08-128b378d-8656-4907-ad70-b876a161c82d.xlsx
- spdx: https://github.com/lfscanning/spdx-lfai/tree/master/JanusGraph/2022-07/JanusGraph-2022-08-08.spdx

Please feel free to contact me with any questions about the scan results. Be sure to reply to me directly as I may not get an email sent directly to the distribution list. Since this is the first license scan for this project, if you have any general questions about the scanning process you can let me know that too.

Thanks, Jeff

Jeff Shapiro
408-910-7792
jshapiro@...


Re: Regarding DB

Kalpa 1977
 

Thanks for the clarifications.
Kalpa

On Sun, Jul 31, 2022 at 3:46 PM <hadoopmarc@...> wrote:

[Edited Message Follows]

1. Sure, see: https://github.com/JanusGraph/janusgraph/blob/master/LICENSE.txt

2. JanusGraph backends are not columnar in the usual meaning of the word, but rather assume a BigTable like KeyColumnValue store, see https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/diskstorage/keycolumnvalue/KeyColumnValueStore.java
This provides better horizontal scalability than technologies like solr/elacticsearch. A KeyColumnValue store client can see from the partitioned key which backend node to address, while solr/elastic involves a server-side routing step to direct a query to the right shard when requesting a specific document by id. This might be different for your inhouse store, though, so check whether it can implement the interface above efficiently. You may also want to check https://li-boxuan.medium.com/janusgraph-deep-dive-data-layout-in-janusgraph-cd33c045a495 whether your store supports this data layout.


Re: Regarding DB

hadoopmarc@...
 
Edited

1. Sure, see: https://github.com/JanusGraph/janusgraph/blob/master/LICENSE.txt

2. JanusGraph backends are not columnar in the usual meaning of the word, but rather assume a BigTable like KeyColumnValue store, see https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/diskstorage/keycolumnvalue/KeyColumnValueStore.java
This provides better horizontal scalability than technologies like solr/elacticsearch. A KeyColumnValue store client can see from the partitioned key which backend node to address, while solr/elastic involves a server-side routing step to direct a query to the right shard when requesting a specific document by id. This might be different for your inhouse store, though, so check whether it can implement the interface above efficiently. You may also want to check https://li-boxuan.medium.com/janusgraph-deep-dive-data-layout-in-janusgraph-cd33c045a495 whether your store supports this data layout.


Regarding DB

Kalpa 1977
 

Hi All,
    My company has a inhouse db like elasticsearch but only index based search, no columnar.
I see that janusgraph mostly has columnar db as the primary data storage.
1. can we plugin our own db, is it allowed?
2. why only columnar as the primary db, any reasons.
   index based lucene also can support like getting all the indexed documents.
any reason why columnar as the primary backend?
thanks,
Kalpa


[ANNOUNCE] JanusGraph 0.6.2 Release

Oleksandr Porunov
 

The JanusGraph Technical Steering Committee is excited to announce the release of JanusGraph 0.6.2.

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.2

A full binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.2/janusgraph-full-0.6.2.zip
 
A truncated binary distribution is provided:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.6.2/janusgraph-0.6.2.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/23?closed=1

Thank you very much,
Oleksandr Porunov
on behalf of JanusGraph TSC


[RESULT][VOTE] JanusGraph 0.6.2 release

Oleksandr Porunov
 

This vote is now closed with a total of 3 +1s, no +0s and no -1s. The results are:

BINDING VOTES:

+1  (3 -- Florian Hockmann, Oleksandr Porunov, Jan Jansen)
0   (0)
-1  (0)

NON-BINDING VOTES:

+1 (0)
0  (0)
-1 (0)

Thank you very much,
Oleksandr Porunov


Re: [DISCUSS] Discord Server

Florian Hockmann
 

Thanks for your feedback, Oleksandr.

 

We now have 3 people here on the dev list in favour of starting a Discord Server and no one against it. Only one user responded on janusgraph-users in the thread you linked, and that user was also in favour of Discord. I also asked people on Gitter for their opinion [1] but didn’t really get a response there. Since also nobody on Gitter voiced concerns about moving to Discord, I don’t really see a reason against starting a Discord Server.

 

So, I went ahead and created a server. You can join via this link: https://discord.gg/5MnxF82VGw

I’d say we wait a week or so before promoting it also to users, so we have some time to use and test the server ourselves.

 

Regarding links between the TinkerPop server and our own: We can probably create some kind of “welcome” channel where we briefly explain the channels of our own server and then also link to the TinkerPop server for general Gremlin questions. TinkerPop already has such a welcome channel, and we can later ask to be linked there for JanusGraph specific questions.

 

[1]: https://gitter.im/janusgraph/janusgraph?at=6284afb0bd487e746b5c790f

 

Von: janusgraph-dev@... <janusgraph-dev@...> Im Auftrag von Oleksandr Porunov
Gesendet: Mittwoch, 1. Juni 2022 12:53
An: janusgraph-dev@...
Betreff: Re: [janusgraph-dev] [DISCUSS] Discord Server

 

Related thread in Users group: https://lists.lfaidata.foundation/g/janusgraph-users/topic/discuss_moving_from_gitter/91181812

1 - 20 of 1596