Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

Hmmmmm, if there is no work for the loader the log file wont be churning right?  I think to keep it simple at this point just wait for exit as you originally stated, knowing that there are perhaps some edge cases.  If we need something better we can think of how to do it and add it later.  Ok?

 

From: [mailto:] On Behalf Of Black, Carey M.
Sent: Tuesday, September 12, 2017 11:57 AM
To: Dennis Roberts <>;
Subject: RE: [grouper-users] Grouper Loader Liveness Probe

 

Dennis,

 

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.

 

--

Carey Matthew

 

From: [] On Behalf Of Dennis Roberts
Sent: Monday, September 11, 2017 9:19 PM
To:
Subject: [grouper-users] Grouper Loader Liveness Probe

 

Hey Everyone,

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?

Thanks,
Dennis