[GitHub] [tinkerpop] spmallette commented on pull request #1285: Tinkerpop-1641 Kerberos authentication for gremlin-python

[GitBox <gi...@apache.org>]

spmallette commented on pull request #1285:
URL: https://github.com/apache/tinkerpop/pull/1285#issuecomment-628593510


   Sorry, it took me a bit to get to this:
   
   > This feature (Kerberos for gremlin-python) turned out to have a pretty large footprint because of the need to make the KDC server available in both gremlin-test and the gremlin-server-test docker container. 
   
   yep - that spun out of control quickly :)
   
   > I am not entirely sure whether the gremlin-test jar-with-dependencies is the cleanest way to make the KDC available in the Docker container.
   
   That struck me as well in review. My initial reaction was that I'd like to keep `gremlin-test` isolated to Gremlin provider testing and to move re-usable test components somewhere else. I think we have other odds and ends like this KDC fixture. I'll need to think about that a bit more.
   
   > Because of the sheer complexity of Kerberos configs and error messages I thought it useful to document the transcripts of the manual connections made against the gremlin-server-test docker container. If reviewers feel the same, please state what is the best location for it (possibly not the current location docker/gremlin-server/docker-entrypoint.sh).
   
   I liked that bit of documentation actually. I was content with where you put it for now, but I will think so more on it.
   
   > Does anyone with knowledge of gremlin-dotnet see what is the matter? All earlier travis builds (red crosses above) only failed on gremlin-python, so if gremlin-dotnet builds are consistent, the current failure suggests the addition of the gcc and python3.6-dev packages would somehow interfere with dotnet.
   > If no ideas pop up, I will revert and reapply the gcc and python3.6-dev changes later this week and see what happens.
   > What is there to do to stop travis whining?
   
   Travis is flakey and I don't think it's our tests that cause the trouble. The environment fails for all sorts of reasons (e.g. internet connections die, VMs randomly timeout for no reason, etc). I've yet to see a pattern of failure that involves anything we can fix on our end unfortunately. I pretty much just look for clear test failures in Travis as things to worry about and just re-run tests as needed that failed to get a green run. I also mostly rely on my own local build. If i get a clean build with `mvn` and a good docker build locally it should be pretty solid.
   
   Travis seems happier now so whatever was the matter seems resolved. There was a failure with spark as of your last commit but I assume that's nothing. I restarted it and seems happy now
   
   I'll start thinking about the items I mentioned above to see what changes I might suggest. Thanks for the work on this. 
   
   
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org