Florian Hockmann <f...@...>
toggle quoted message
Show quoted text
Yes, +1 for the separate repo.
Am Dienstag, 21. August 2018 03:04:23 UTC+2 schrieb Ted Wilmes:
Appreciate the extra stir and yes, I'm in agreement. +1 for a separate repo.
On Mon, Aug 20, 2018, 3:14 PM Chris Hupman <ch...@...
Stirring one more time. Ted and Florian are you guys in favor of the creation of a repo for an official JanusGraph docker image?
On Thursday, August 16, 2018 at 8:19:05 AM UTC-7, Jason Plurad wrote:
+1 for a single janusgraph-docker repo.
Wouldn't you be able to use the directory structure to manage the different flavors of a Docker image that we want to publish to Docker Hub? I wouldn't want to create multiple JanusGraph repos for Docker technology.
On Wednesday, August 15, 2018 at 2:25:32 PM UTC-4, Chris Hupman wrote:
Since we seem to be making repos right now I wanted to stir this up a bit. I think right now would be a good time to make a janusgraph-docker repo for an official Docker image.
I mainly wanted to ask if a single repo would be adequate. I personally like the approach of a single image defaulting to in-memory so the image can be deployed standalone and then configuring through -e flags at deploy. In one of the PRs
it was suggested to default to using es and Cassandra. I am assuming, quite possibly incorrectly, that would mean throwing es, Cassandra, and JanusGraph in a single container for ease of deploy. If that was the case an additional repo would probably be required.
Hoping to get some +1s for a consensus on adding a janusgraph-docker repo.
On Thursday, June 7, 2018 at 12:34:30 AM UTC-7, Florian Hockmann wrote:
what if we included a minimal Docker build as part of the repo for
client library testing and then left the separate repo to serve only the
purpose of producing official, published Docker images?
That makes perfectly sense to me. Seems to be the best solution overall to me.
Am Mittwoch, 6. Juni 2018 22:05:18 UTC+2 schrieb Ted Wilmes:
Thanks for the responses Chris and Florian. I'm in agreement that we should first discuss the separate repo issue separate from the implementation details. That was my intent, but by including those two links I conflated the two. I would expect either approach we take to go through the usual PR process, or perhaps even another round of discussion. My Alpine base image example isn't a great one, may main point is that for whatever reason, there may be a community desire to support a variety of different configurations for the images (not Janus configs themselves to be clear).
Your point about client library development is a good one. My inclination is to treat the JanusGraph developer Docker environment use case differently than the JanusGraph end-user use cases (user dev & integration testing, production deployment). There would undoubtedly be some overlap, but what if we included a minimal Docker build as part of the repo for client library testing and then left the separate repo to serve only the purpose of producing official, published Docker images?
On Wednesday, June 6, 2018 at 6:41:50 AM UTC-5, Florian Hockmann wrote:
first of all, big thanks for bringing this up again! I'm really looking forward to an official JanusGraph image.
I can think of one advantage of including the Docker images in the main JanusGraph repo: When you want to test a client library like the ones we will probably create for the different languages (I'm currently working on one for .NET) then you need an instance of the server and this should be a version of the server that will be released with the same version number. A JanusGraph docker image would make testing of such a client library much easier but when we put the Dockerfile in another repo then we would only have already published images available in the main repo. So you couldn't test such a client library with a Docker image of the server as it is at that moment in the repo, you would rather have to use an already released version.
A big advantage of a separate repo would be that we could make use of DockerHub's automated builds which can then also include the README.md and the Dockerfile.
One thing I'm wondering about:
potentially supporting a variety of different linux distros including alpine
What's the advantage of having images for other distros than alpine? Having alpine as the base image means that the image will be really small but do users also want a debian based image or something like that?
I haven't looked into the new repo Chris created in detail as I think that we should first only discuss about whether or not a separate repo should be used and I assume that there will be the usual review process afterwards.
Am Dienstag, 5. Juni 2018 22:52:42 UTC+2 schrieb Chris Hupman:
I'm regularly using containers for Cassandra and Elasticsearch for my JanusGraph work and I had a couple of thoughts on this.
- In pull 700 only janusgraph is being run, in the experoinc repo es, cassandra, and janusgraph are all running in the same container. I personally think JanusGraph only running in-memory by default is the right approach. While an all-in-one is great for development it wouldn't really make sense for a real deployment.
- Right now both containers are using JanusGraphFactory(JGF) instead of ConfiguredGraphFactory(CGF). Since this container is for running JanusGraph server I think CGF would make more sense than JGF.
- To be more modular and avoid passing as many -e flags it should support multiple gremlin server files through ENVs.
- For JGF deployments we should add in a script to bind g = graph.traversal() to improve user experience as referenced in the docs
- For CGF deployments it would be nice if the container tried to create a template using the configuration parameters it already had access to.
- I think it makes sense to house the docker components and tests in a separate repo. With the approach of downloading the release and moving it to /opt/janusgraph it would be easy to run a script afterwards to update the yaml and property files to take ENVs.
I think this would be great for the overall health of the project and I'm willing to help out with code, docs, and/or testing.
On Tuesday, June 5, 2018 at 9:33:42 AM UTC-7, Ted Wilmes wrote:
I wanted to restart a discussion on producing an official JanusGraph Docker image. There is lots of community interest and progress has been made but we're not quite there yet. There is an existing PR  that a coworker of mine, Chris Pounds, had been working on. After some brainstorming with Misha Brukman, we were wondering if a change in approach may make sense. Namely, that it might be a good idea to host the artifacts required to maintain Janus docker images separate from the main JanusGraph repo. With that in mind, Chris has recently created this repo: https://github.com/experoinc/janusgraph-images
. It's sitting under out GitHub at the moment but is Apache 2 licensed, and if this plan makes sense to folks, we'd just transition it over to the Janus org and put it through the usual PR and approval process. With all that said, I think there are a number of benefits to maintaining the Docker plumbing separate from JanusGraph itself. I would imagine a matrix of different versions and image options at some point, potentially supporting a variety of different linux distros including alpine. Also, it would be nice to be able to version the Docker artifacts separately from JanusGraph so that we can rev them at different speeds. So, first step is I'd like to get some community feedback on this approach and see what folks thought about setting up a separate repo under the Janus org to host the Docker plumbing?
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/V70uVxh9who/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgraph-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/d2da37b0-44c1-4c3b-b51b-58e279bdeefa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.