Date   

Re: [DISCUSS] Moving toward an initial release

"P. Taylor Goetz" <ptg...@...>
 

I think that’s a sound approach. Having an easy migration path from Titan to JanusGraph will encourage adoption and help build community.

-Taylor

On Mar 9, 2017, at 12:00 PM, sjudeng <sju...@...> wrote:

Let me know if this should be moved to another thread but is there any interest in scoping down the initial JanusGraph release to just be a "compatibility" release? There has been concern raised in discussions (for example here) that some users on production Titan systems would benefit from an initial release that has no breaking changes, especially to core storage, indexing and compute system components. There are already potentially breaking changes in master such as the TinkerPop update and others are in work.

Beyond mitigating concerns regarding having an initially easy migration step from Titan to JanusGraph, pursing a release branch without the additional features and dependency updates currently in work would allow for a relatively more rapid (and hopefully more stable) initial JanusGraph release. Any feedback on inevitable compatibility issues could then be addressed to the benefit of the subsequent JanusGraph release.

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Moving toward an initial release

Adam Phelps <a...@...>
 

Yeah, I agree completely here.

The TinkerPop update to me is a very different breaking change, since it just requires some minor code changes vs needing to upgrade clusters.

- Adam Phelps

On 3/9/17 10:35 AM, P. Taylor Goetz wrote:
I think that’s a sound approach. Having an easy migration path from
Titan to JanusGraph will encourage adoption and help build community.

-Taylor

On Mar 9, 2017, at 12:00 PM, sjudeng <sju...@...
<mailto:sju...@...>> wrote:

Let me know if this should be moved to another thread but is there any
interest in scoping down the initial JanusGraph release to just be a
"compatibility" release? There has been concern raised in discussions
(for example here
<https://groups.google.com/forum/#!msg/janusgraph-dev/F-zfIsuiIoQ/TFsMMa59BAAJ>)
that some users on production Titan systems would benefit from an
initial release that has no breaking changes, especially to core
storage, indexing and compute system components. There are already
potentially breaking changes in master such as the TinkerPop update
and others are in work.

Beyond mitigating concerns regarding having an initially easy
migration step from Titan to JanusGraph, pursing a release branch
without the additional features and dependency updates currently in
work would allow for a relatively more rapid (and hopefully more
stable) initial JanusGraph release. Any feedback on inevitable
compatibility issues could then be addressed to the benefit of the
subsequent JanusGraph release.


Re: [PROPOSAL] CQL Storage Backend Implementation

Jason Plurad <plu...@...>
 

Thanks for sharing your branch. I tried out your backend, and it worked fine. I verified that it is storage compatible with the cassandrathrift driver. Good stuff. I opened a PR on your repo to handle a few things.

I'm +0 on Javaslang as a new dependency. License looks fine, and I assume its performance is reasonable close to plain old Java?

-- Jason


On Wednesday, March 8, 2017 at 7:49:20 PM UTC-5, Samant Maharaj wrote:
Hi all,

We've got an initial implementation of the CQL based backend. At this stage it's been implemented as a completely separate module, however ideally we'd like to extract a cassandra-core module for common code.


Features left to implement:
  • Pooling configuration
  • Retry configuration
  • Support for per partition query limits (available in C* since 3.6). We're planning to implement this by switching the query strategy based on the version metadata detected from the C* cluster.
Note, we've introduced dependencies on the Datastax Cassandra driver as well as Javaslang which makes functional style programming in Java a lot easier.

It'd be great to get some feedback to ensure we're not going about this the wrong way.

Regards,
Samant Maharaj & Paul Kendall.

On Wednesday, 8 March 2017 06:47:05 UTC+13, Paul Kendall wrote:
Jason, currently we are targetting the 3.1.4 driver, but I don't think there is anything that precludes us from using the 3.3 version either, but I will check on that.
We will look into completing the unit tests today then we'll comment on https://github.com/JanusGraph/janusgraph/issues/35 with a link to our fork so we can get feedback.
We'll also look into creating a cassandra-core project that can be used to contain common code for all the cassandra variants.


Re: [DISCUSS] Moving toward an initial release

sjudeng <sju...@...>
 

The TinkerPop update is relevant because it would require production users of OLAP capabilities to upgrade their compute clusters (e.g. from Spark 1.2 to Spark 1.6).


Re: [PROPOSAL] CQL Storage Backend Implementation

Paul Kendall <paul....@...>
 

Thanks Jason, Samant has merged your PR and changed the section of processing the contact points to a more functional style and you'll see that it's a lot easir to read and understand. That's part of the reason we like using javaslang. It makes the code simpler and more concise with less boilerplate. It's similar to googles guave library but a lot more functional and has a very active community behind it.

On Friday, March 10, 2017 at 11:46:59 AM UTC+13, Jason Plurad wrote:
Thanks for sharing your branch. I tried out your backend, and it worked fine. I verified that it is storage compatible with the cassandrathrift driver. Good stuff. I opened a PR on your repo to handle a few things.

I'm +0 on Javaslang as a new dependency. License looks fine, and I assume its performance is reasonable close to plain old Java?

-- Jason

On Wednesday, March 8, 2017 at 7:49:20 PM UTC-5, Samant Maharaj wrote:
Hi all,

We've got an initial implementation of the CQL based backend. At this stage it's been implemented as a completely separate module, however ideally we'd like to extract a cassandra-core module for common code.


Features left to implement:
  • Pooling configuration
  • Retry configuration
  • Support for per partition query limits (available in C* since 3.6). We're planning to implement this by switching the query strategy based on the version metadata detected from the C* cluster.
Note, we've introduced dependencies on the Datastax Cassandra driver as well as Javaslang which makes functional style programming in Java a lot easier.

It'd be great to get some feedback to ensure we're not going about this the wrong way.

Regards,
Samant Maharaj & Paul Kendall.

On Wednesday, 8 March 2017 06:47:05 UTC+13, Paul Kendall wrote:
Jason, currently we are targetting the 3.1.4 driver, but I don't think there is anything that precludes us from using the 3.3 version either, but I will check on that.
We will look into completing the unit tests today then we'll comment on https://github.com/JanusGraph/janusgraph/issues/35 with a link to our fork so we can get feedback.
We'll also look into creating a cassandra-core project that can be used to contain common code for all the cassandra variants.


Re: [DISCUSS] Moving toward an initial release

"P. Taylor Goetz" <ptg...@...>
 

My guess would be that end users might want as close to drop in replacement for Titan as possible, at least initially. That would at least give them the opportunity to move from an essentially EOL'd solution (Titan) to one with a future (JanusGraph). In other words, it would send the message that JanusGraph is a serious and viable continuation of Titan.

In terms of community development, IMHO it would be best to get users moved over to JanusGraph as quickly as possible. The sooner that happens, the sooner we get actual user feedback that can help better inform the project's technical direction.

-Taylor

On Mar 9, 2017, at 7:06 PM, sjudeng <sju...@...> wrote:

The TinkerPop update is relevant because it would require production users of OLAP capabilities to upgrade their compute clusters (e.g. from Spark 1.2 to Spark 1.6).

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Moving toward an initial release

Ted Wilmes <twi...@...>
 

In that case, since the disk storage format is unchanged, could we simply suggest that for the time being they could continue running OLAP jobs using their Titan 1.0 install?  There isn't a lot of interaction between OLAP and OLTP at this point aside from bulk loading/exporting.

I agree we should minimize leaving folks behind with version jumps that will require infrastructure upgrades (search & storage), but the titan11 branch that Janus forked off of, though it wasn't at TinkerPop 3.2.3, had progressed beyond the 3.0.2 release and I feel that there was a general consensus that it was a reasonable starting point.  I suppose we could cut a release from pre-upgrade to 3.2.3, but at that point, we'd still be ahead of folks running Titan 1.0 with the TP version 3.1.1.  I thinking getting Janus up to TinkerPop 3.2.3 or possibly even 3.2.4 depending on the timing is a big value add for people interested in kicking the tires and production users.  Having said that, perhaps we should start a thread that includes concrete examples of what a TinkerPop upgrade would mean to a Janus user coming from Titan and get feedback from the community on the level of pain this would cause them.

--Ted

On Thu, Mar 9, 2017 at 6:06 PM, sjudeng <sju...@...> wrote:
The TinkerPop update is relevant because it would require production users of OLAP capabilities to upgrade their compute clusters (e.g. from Spark 1.2 to Spark 1.6).

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developer list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/8jkMnkKzmC0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Moving toward an initial release

sjudeng <sju...@...>
 

That's a good point that titan11 was already at Spark 1.5 via TinkerPop 3.1.0. At that point including TinkerPop 3.2.3 probably isn't going to make much difference in terms of migration. If that's fine then a release branch (0.1-SNAPSHOT) could be created right now off the tip of master. If going with TinkerPop 3.2.3 it might be worth considering releasing JanusGraph as 0.2.0 if there was intention to tie versioning to TinkerPop.

If the goal is to try and move out relatively quickly on an initial release then I wouldn't wait for the update to TinkerPop 3.2.4 or really any other new feature/dependency update unless it's a true blocker. Looking over existing PRs and 0.1.0 release milestone issues it appears to me that resolving the below items would be sufficient for the initial "compatibility" release. The other issues are either done or in my opinion don't need to block a release if they can't be immediately addressed.

  • #80 - Backward compatibility with Titan. Action: Needs to be merged.
  • #132 - Non-permissive license issue. Action: Need confirmation that dependency licenses are okay as-is at least for the initial release
  • (Optionally) #98 - GitHub releases deployment via Travis. Necessary only if using GitHub releases for deploying zipfile artifacts for tagged releases. Action: Needs to be merged.


Re: [VOTE] Elasticsearch upgrade

Jason Plurad <plu...@...>
 

VOTE: +1


On Thursday, March 9, 2017 at 12:13:59 PM UTC-5, sjudeng wrote:
I'd like to request a vote on the following proposal for proceeding with updates to Elasticsearch in JanusGraph (see this discuss thread for more information):

  1. Update to support ES 2.x and 5.x with native ES REST client. This work is complete and available for review in #79.
  2. Update to remove transport client and replace native ES REST client with the Jest high level ES HTTP client. This work is in progress and being tracked in #160.


Re: [VOTE] Elasticsearch upgrade

Keith Lohnes <loh...@...>
 

VOTE: +1


On Fri, Mar 10, 2017 at 11:03 AM Jason Plurad <plu...@...> wrote:
VOTE: +1


On Thursday, March 9, 2017 at 12:13:59 PM UTC-5, sjudeng wrote:
I'd like to request a vote on the following proposal for proceeding with updates to Elasticsearch in JanusGraph (see this discuss thread for more information):

  1. Update to support ES 2.x and 5.x with native ES REST client. This work is complete and available for review in #79.
  2. Update to remove transport client and replace native ES REST client with the Jest high level ES HTTP client. This work is in progress and being tracked in #160.

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
For more options, visit https://groups.google.com/d/optout.


Re: [VOTE] Elasticsearch upgrade

Dylan Bethune-Waddell <dylan.bet...@...>
 

+1


On Thursday, March 9, 2017 at 12:13:59 PM UTC-5, sjudeng wrote:
I'd like to request a vote on the following proposal for proceeding with updates to Elasticsearch in JanusGraph (see this discuss thread for more information):

  1. Update to support ES 2.x and 5.x with native ES REST client. This work is complete and available for review in #79.
  2. Update to remove transport client and replace native ES REST client with the Jest high level ES HTTP client. This work is in progress and being tracked in #160.


Re: [VOTE] Elasticsearch upgrade

Nigel Brown <nigel...@...>
 

+1


Re: [DISCUSS] Moving toward an initial release

Ted Wilmes <twi...@...>
 

I think that's a solid list. If #159 gets through review, I'd be interested in having it included. WIthout it, bulk loads via the BulkLoaderVertexProgram become untenable due to unnecessary full vertex scans. If we can come to consensus on this list, shall we set a freeze date at some point in the not too distant future and then start working through the release steps? Maybe step 1 at that point should be publishing a snapshot followed by going through the full process.

--Ted

On Thu, Mar 9, 2017 at 9:32 PM, sjudeng <sju...@...> wrote:
That's a good point that titan11 was already at Spark 1.5 via TinkerPop 3.1.0. At that point including TinkerPop 3.2.3 probably isn't going to make much difference in terms of migration. If that's fine then a release branch (0.1-SNAPSHOT) could be created right now off the tip of master. If going with TinkerPop 3.2.3 it might be worth considering releasing JanusGraph as 0.2.0 if there was intention to tie versioning to TinkerPop.

If the goal is to try and move out relatively quickly on an initial release then I wouldn't wait for the update to TinkerPop 3.2.4 or really any other new feature/dependency update unless it's a true blocker. Looking over existing PRs and 0.1.0 release milestone issues it appears to me that resolving the below items would be sufficient for the initial "compatibility" release. The other issues are either done or in my opinion don't need to block a release if they can't be immediately addressed.

  • #80 - Backward compatibility with Titan. Action: Needs to be merged.
  • #132 - Non-permissive license issue. Action: Need confirmation that dependency licenses are okay as-is at least for the initial release
  • (Optionally) #98 - GitHub releases deployment via Travis. Necessary only if using GitHub releases for deploying zipfile artifacts for tagged releases. Action: Needs to be merged.

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developer list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/8jkMnkKzmC0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Moving toward an initial release

sjudeng <sju...@...>
 

I'm not familiar with the proposed released process. The JanusGraph release docs appear to start with a candidate release already ready to be deployed but not how it's prepared/vetted. Personally I'd like to see ongoing development and release preparation work be broken out into different branches. On the release side it puts good visibility on what exactly will be the basis for the release and then also allows non-release development to continue without getting held up.

It sounds like #159 should definitely be included. I'd hope after this long that any other critical features/fixes for an initial release have already been identified on GitHub issues/PRs and there should be some resistance to delaying the release at all at this point except for really critical blockers. Hopefully keeping it scoped down to just a couple PRs to review/merge will help make this more manageable for committers (which I'm not, so I can't help on this part).



Re: [VOTE] Elasticsearch upgrade

Jason Plurad <plu...@...>
 

This vote has been open for 5 days... and the results are:

+1 [4 votes]
 0 [0 votes]
-1 [0 votes]

The proposal is approved. Thank you sjudeng and Keith!


On Thursday, March 9, 2017 at 12:13:59 PM UTC-5, sjudeng wrote:
I'd like to request a vote on the following proposal for proceeding with updates to Elasticsearch in JanusGraph (see this discuss thread for more information):

  1. Update to support ES 2.x and 5.x with native ES REST client. This work is complete and available for review in #79.
  2. Update to remove transport client and replace native ES REST client with the Jest high level ES HTTP client. This work is in progress and being tracked in #160.


Re: [DISCUSS] Moving toward an initial release

Jason Plurad <plu...@...>
 

Agreed, creating a separate branch for the initial release and ongoing development makes sense. I'll be reviewing #159 this afternoon. Others are encouraged to review it also.

> help make this more manageable for committers (which I'm not, so I can't help on this part).

Disagree on the part in parens... this is an open community project and anybody who wants to contribute to JanusGraph can help move the project forward can do so by communicating on the mailing lists, on issues, and on pull requests. Your participation in all venues has done a lot for JanusGraph so far and is greatly appreciated!


On Friday, March 10, 2017 at 4:22:22 PM UTC-5, sjudeng wrote:
I'm not familiar with the proposed released process. The JanusGraph release docs appear to start with a candidate release already ready to be deployed but not how it's prepared/vetted. Personally I'd like to see ongoing development and release preparation work be broken out into different branches. On the release side it puts good visibility on what exactly will be the basis for the release and then also allows non-release development to continue without getting held up.

It sounds like #159 should definitely be included. I'd hope after this long that any other critical features/fixes for an initial release have already been identified on GitHub issues/PRs and there should be some resistance to delaying the release at all at this point except for really critical blockers. Hopefully keeping it scoped down to just a couple PRs to review/merge will help make this more manageable for committers (which I'm not, so I can't help on this part).



[DISCUSS] The first SNAPSHOT

Ted Wilmes <twi...@...>
 

Hi everyone,
Thanks to Taylor we have our Nexus account setup. I was going to grab issue #40 and work on 
deploying the first Janus snapshot but wanted to double check with folks to see if there were any objections. 
I'll assume lazy consensus in 72 hours and go forward unless I hear otherwise.

Thanks,
Ted


Re: [DISCUSS] The first SNAPSHOT

"P. Taylor Goetz" <ptg...@...>
 

+1 I say go for it.

-Taylor

On Mar 16, 2017, at 9:15 AM, Ted Wilmes <twi...@...> wrote:

Hi everyone,
Thanks to Taylor we have our Nexus account setup. I was going to grab issue #40 and work on 
deploying the first Janus snapshot but wanted to double check with folks to see if there were any objections. 
I'll assume lazy consensus in 72 hours and go forward unless I hear otherwise.

Thanks,
Ted

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] The first SNAPSHOT

Jerry He <jerr...@...>
 

Sounds good.  Are these going to be the zip and/or all the maven artifacts?

Jerry


Re: [DISCUSS] The first SNAPSHOT

Ted Wilmes <twi...@...>
 

Yes, that's what I was thinking.

Thanks,
Ted

On Thu, Mar 16, 2017 at 11:32 PM, Jerry He <jerr...@...> wrote:
Sounds good.  Are these going to be the zip and/or all the maven artifacts?

Jerry

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developer list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/MtuHdULB8zM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgraph-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

81 - 100 of 1585