There have been some important updates to the way the Neo4j helm chart works.
The code will now reside in this repository:
Artifact Hub Link
Previously, many users had been using this chart, but it has now been deprecated in favor of the one linked above. The old repo is itself being slowly phased out by helm, and maintainers are encouraged to self-host their helm charts, which we've done.
We have already created a release of the new helm chart that supports Neo4j 4.0.4, and has a bunch of extra features & goodies that the deprecated one does not, including memory configuration settings, prometheus monitoring, and more.
I am using the latest code from neo4j helm repo : https://github.com/neo4j-contrib/neo4j-helm, to deploy a neo4j server using helm.
I have cloned the repo and ran the following command:
helm install my-neo4j neo4j-helm --set core.standalone=true --set acceptLicenseAgreement=yes --set neo4jPassword=mypassword from outside the repository.
Command runs without any error. Also, the pod and service are up and running. I am even able to telnet to the pod IP with port 7687, but when I am trying to connect to the Neo4j cluster via Neo4j Desktop it is giving me the following error:
Unable to establish remote connection: Database is unreachable with specified configuration.
Unable to establish remote connection: AUTHENTICATION_FAILURE
I am using the following parameters to login via Neo4j Desktop:
- Connect URL: bolt://pod-IP-address:7687
- Username: neo4j
- Password: mypassword
Following are the logs of the pod:
Warning: Some files inside "/data" are not writable from inside container. Changing folder owner to neo4j.
Changed password for user 'neo4j'.
Fetching versions.json for Plugin 'apoc' from https://neo4j-contrib.github.io/neo4j-apoc-procedures/versions.json
Installing Plugin 'apoc' from https://github.com/neo4j-contrib/neo4j-apoc-procedures/releases/download/22.214.171.124/apoc-126.96.36.199-all.jar to /plugins/apoc.jar
Applying default values for plugin apoc to neo4j.conf
Directories in use:
APOC couln't set a URLStreamHandlerFactory since some other tool already did this (e.g. tomcat). This means you cannot use s3:// or hdfs:// style URLs in APOC. This is caused by a limitation of the JVM which we cannot fix.
2020-11-02 13:56:42.549+0000 INFO Starting...
2020-11-02 13:56:44.534+0000 INFO ======== Neo4j 4.1.3 ========
2020-11-02 13:56:47.286+0000 INFO Called db.clearQueryCaches(): Query cache already empty.
2020-11-02 13:56:51.796+0000 INFO Sending metrics to CSV file at /var/lib/neo4j/metrics
2020-11-02 13:56:51.814+0000 INFO Bolt enabled on 0.0.0.0:7687.
2020-11-02 13:56:52.514+0000 INFO Remote interface available at http://my-neo4j-neo4j-core-0.my-neo4j-neo4j.data.svc.cluster.local:7474/
2020-11-02 13:56:52.514+0000 INFO Started.
2020-11-02 13:59:20.276+0000 WARN The client is unauthorized due to authentication failure.
2020-11-02 13:59:46.872+0000 WARN The client is unauthorized due to authentication failure.
2020-11-02 14:26:55.553+0000 WARN The client is unauthorized due to authentication failure.
Can anyone help me with this?
Also, this issue is quite strange. I was able to connect via Neo4j desktop previously, but today when I launched it again it giving me this error
Is it something to do with Enterprise License?
This is nothing to do with the enterprise license, it has to do with networking outside of kubernetes & into kubernetes.
By default desktop connects with the neo4j:// protocol which requires additional networking setup for kubernetes. You have two options:
- You can try bolt:// instead of Neo4j to eliminate driver routing. This may fix it, and would work fine for a single instance but would be a problem for clusters.
- You can follow these instructions here and setup external exposure for any Neo4j instance in kubernetes, this will enable neo4j:// to work as you expect. External Exposure of Neo4j Clusters - Neo4j-Helm User Guide
I am using bolt:// only in the connect url
please read the external exposure instructions, they have a very detailed discussion of what's going on with network contacts from outside of kubernetes into a kubernetes instance. If you've read those docs, then please come back with examples of what the inside of your system looks like, what you've done, and what's not working.
I have gone through the doc before. We are accessing the Neo4j cluster inside Kubernetes only so we do not require provisioning static IPs and the load balancer for it.
So, I launched the cluster and tried to access the Neo4j cluster as per my requirement from another Kubernetes pod. It worked fine back then, so I tried to use bolt:// routing directly on the standalone cluster's pod IP address and access the same via Neo4j Desktop. I was able to do this as well some days back.
But today when I tried the same, it started throwing the above-mentioned error. There was nothing significant in the logs, so I am posting here to find some other way to debug this.
Today as well, I was able to access the cluster via Neo4j Desktop once... After that, it started failing for no reason. This error is very random so I wanted to debug it before moving it to production.
Also, I wanted to know exactly when is the Enterprise License required? Because I was able to launch multi-node cluster from this helm chart as well, and it did not require a License anywhere...
Is a license required in case of internal use only as well?
A license is required to run Neo4j Enterprise, but this license is a paper legal agreement or form you do via our website. Concretely there is no "product key" that you have to configure the software to use. The only requirement there is that acceptLicenseAgreement=yes for your helm install, as is in the documentation.
License is for some sort of extra customer support? Or is it optional?
License is required to run Neo4j Enterprise legally, it is not optional. Via the site you can obtain a 30-day trial license, and there are other programs such as the startup & educational programs where you can obtain valid licenses. Separately, yes it's also required to access support. Licenses which have support plans get support accounts set up.
Hey @david_allen any clue on why I am not able to connect from Neo4j Desktop via
bolt:// route to the standalone cluster? There is nothing significant in the logs so I am not able to debug it further.
PS: I am able to telnet to the pod IP with 7687 port, and the same IP I am providing in the Connect URL which is
I don't know. By default, if you were to install a standalone instance in Kubernetes, there would be no way to connect to it from the outside world at all. In order to make this possible you must do some extra configuration, but you haven't stated what configuration or install method you've used. You'd need to provide much more information here, such as what helm install command you used, what your neo4j config looks like, what the IP address is, and it'd also be helpful to know what kind of kubernetes
Sorry, for the lack of context here. Our DevOps team have set up the Kubernetes cluster for us, so little unsure of the exact configuration done for the same, but I was able to telnet the internal IP address of the pod( our DevOps team must have configured it to be available over VPN ) running the Neo4j cluster, so I tried to connect the same via Neo4j Desktop. And, I was able to access it as well on my first try, but it was failing on the second try.
I debugged the issue and found out that when I was uninstalling the helm chart of Neo4j and installing it again I had changed the password for the new deployment, but it was not picking the new password due to persistent volumes of the previous deployment being still present... I tried deleting the pvc(persistentVolumeClaim) for the old deployment and this time I was able to connect it
Yes, when you first install the chart and provide an initial password, it gets persisted to the system database. If you uninstall and reinstall, the old PVCs are still there and you can't "re-set an initial password". Deleting the PVCs is the way to go, but this doesn't happen for you automatically since if that were done, you'd lose all database state. Users should always take that step manually