Subject: Grouper Users - Open Discussion List
- From: "Black, Carey M." <>
- To: Dennis Roberts <>, "" <>
- Subject: RE: [grouper-users] Grouper Loader Liveness Probe
- Date: Tue, 12 Sep 2017 15:56:49 +0000
- Accept-language: en-US
- Authentication-results: spf=pass (sender IP is 126.96.36.199) smtp.mailfrom=osu.edu; cyverse.org; dkim=none (message not signed) header.d=none;cyverse.org; dmarc=pass action=none header.from=osu.edu;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
I think your assumption that “on fail the process would exit” is faulty.
I think that these conditions can happen:
Log file system fills ( process can hang and not exit )
Java out of ram conditions ( process can hang and not exit )
I would imagine there are other such failure modes too.
However, the only thing that I could think of for a “pulse” would be to parse a log file to monitor activity. ( Then see above comment about filling the log file system. L ) Hopefully someone else will have a better idea.
I’m trying to get Grouper running inside our Kubernetes cluster. So far, it’s working very well but I wasn’t sure what to use for a liveness probe for the Grouper Loader. (A liveness probe simply probes the container to determine whether or not the service needs to be restarted.) My initial feeling with the loader is that a liveness probe probably isn’t really necessary. If the loader fails then I would expect it to throw an exception and exit, which would be detected by Kubernetes because the container would also exit.
I wanted to check with everyone here to see what their thoughts are, however. Can anyone think of any common situations where the Grouper loader would have to be forcibly stopped and restarted?
- [grouper-users] Grouper Loader Liveness Probe, Dennis Roberts, 09/12/2017
Archive powered by MHonArc 2.6.19.