Add startupProbe (#97)

charts/stardog/templates/statefulset.yaml

@@ -139,11 +139,17 @@ spec:
           {{ .Files.Get "files/utils.sh" | indent 10 }}
           make_temp ${STARDOG_TMP_PATH}
           /opt/stardog/bin/stardog-admin server start --foreground --port ${PORT} --home ${STARDOG_HOME} ${STARDOG_SERVER_START_ARGS}
+        startupProbe:
+          httpGet:
+            path: /admin/alive
+            port: server
+          periodSeconds: {{ .Values.startupProbe.periodSeconds }}
+          timeoutSeconds: {{ .Values.startupProbe.timeoutSeconds }}
+          failureThreshold: {{ .Values.startupProbe.failureThreshold }}
         livenessProbe:
           httpGet:
             path: /admin/alive
             port: server
-          initialDelaySeconds: {{ .Values.livenessProbe.initialDelaySeconds }}
           periodSeconds: {{ .Values.livenessProbe.periodSeconds }}
           timeoutSeconds: {{ .Values.livenessProbe.timeoutSeconds }}
         readinessProbe:

charts/stardog/values.yaml

@@ -104,10 +104,15 @@ log4jConfig:
   # we provide a default log4j2.xml, if you want to provide your own. in your own values.yaml, set log4Config.override: true, and log4Config.content
   # content: null
 
-# Stardog liveness probe settings. Consider increasing initialDelaySeconds on clouds where
-# storage provisioning is slower. It is not generally required to modify periodSeconds and timeoutSeconds.
+# Stardog startup probe settings. This gives the database 6 hours to start,
+# e.g. if it needs to rebuild its index if necessary.
+startupProbe:
+  periodSeconds: 30
+  timeoutSeconds: 15
+  failureThreshold: 720
+
+# Stardog liveness probe settings. It is not generally required to modify periodSeconds and timeoutSeconds.
 livenessProbe:
-  initialDelaySeconds: 30
   periodSeconds: 30
   timeoutSeconds: 15