"Application-datastore" not registered for central pod.
I am in the process of automating the deployment of an Apigee cluster. When the install process is completed, I attempt to run the following command to set up the initial organization:
$ apigee-service apigee-provision setup-org -f <provision-file>
It fails with the following error:
!!!! Error !!!!
HTTP STATUS CODE: 500
{
"code" : "organizations.ApplicationDatastoreServerIssue",
"message" : "application-datastore(cassandra) servers are down or not registered for central pod.",
"contexts" : [ ]
}
When I manually log in to the components, I can verify that all required services are running, and (seemingly) set up properly. I've troubleshooted the issue with this procedure, and my results are more or less the same.
I did notice that, as this user has also noted, I don't see "application-datastore" (or anything other than "management-server") listed under the "type" when querying the API for the central pod.
However, the only recommendation the user received was to uninstall and reinstall everything. I can safely say I've repeated the process quite a few times, and as the process is automated, I don't expect anything to be different if I were to continue.
My question is: Where is the field "type" being determined? What step did I apparently skip, which populates the "type" of the management server to contain these other values?
1. Check what pods you have
curl -iu $ADMIN http://$MSIP:$port/v1/regions/<<dc>>/pods
2.Check against central pod to fetch all servers uUid
curl -u $ADMIN:$PW "http://$MSIP:$port/v1/servers?pod=central" | egrep -i '(type|internalip|uuid|region)
3. Verify the servers if they are properly configured to central pod(verify ip's).
curl -iu $ADMIN:$PW http://$MSIP:$port/v1/servers/<<uUID>>
It looks like data store which is in central pod is down or using incorrect configuration.It shouldn't be complex and quick add/remove from the central pod will resolve the issue.
-Vinay
I have three pods: analytics, central, and gateway.
Analytics and gateway are perfectly matched to the troubleshooting procedure I linked in the original post.
Central definitely has something missing.
Originally, like the troubleshooting guide, I thought I was missing the "application-datastore" (among others) from the management server's entry. However, we're using separate instances for Cassandra/Zookeeper (ds). After looking at these pods on a manually-configured cluster, it seems the pods are missing these ds entries entirely.
So my question becomes: how does one attach separate datastore instances to the pods?
Best Answer
Hi @Roman Federici
You can try below curl command to add the missing data store manually to the central pod.
curl -v -u <username>:<password> http://<MSIP:PORT>/v1/servers -X POST -d "type=application-datastore®ion=<regionName>&pod=central∬ernalIP=<CassandraNodeIP>"
Repeat this with each of Cassandra IP in the cluster.
Thanks
Thanks @potturiprasanth!
I came across this post about two hours ago that suggests a similar solution. I had to modify it a bit to work with our cluster, but the successful call was essentially the same. For those who were a bit confused at the "®" and "∫" characters:
curl -X POST -u <user>:<pass> http://<ms_ip>:8080/v1/servers -d "type=application®ion=<region>&pod=central&internalIP=<cs_ip>
Previously, this step was taken care of by the apigee-setup script. I'm not sure why that script is not registering the Cassandra hosts anymore, but manually posting to the API for each Cassandra host seems to work in place.
Thank you!
Roman
P.S. - To "escape" an ampersand, you have to type "&" instead. E.g. "&int" instead of "&int"
This change fixed my issue as well. Just to point out the type should be "application-datastore"
curl -X POST -u <user>:<pass> http://<ms_ip>:8080/v1/servers -d "type=application-datastore®ion=<region>&pod=central&internalIP=<cs_ip>
