Grouper Users - Open Discussion List

[Bill Thompson <>]

sounds reasonable.  do you already have such a script?

On Sat, Jun 8, 2019 at 10:14 AM Scott Koranda
<> wrote:
>
> Hi,
>
> Some deployers using the TAP (formerly TIER) Grouper image will be using
> a relational database and subject source(s) which are themselves
> provided by instantiating containers as part of the same orchestration
> instantiating the Grouper container(s).
>
> In such scenarios the order in which the containers are instantiated is
> not always deterministic. Further, even though a container may be "up"
> it may not yet be ready to receive queries from a Grouper container.
>
> Ideally the Grouper container(s) would not fully start until the
> containers providing the relational database and subject source(s) are
> known to be ready.
>
> I think this can be achieved with Grouper 2.4.x by making enhancements
> to the TAP Grouper image.
>
> I believe Shilen not too long ago made it possible to run GSH bash scripts
> that exit with non-zero return values when the script "fails".
>
> So the TAP Grouper image could include two GSH scripts:
>
> 1) A script that probes whether Grouper can connect to its configured
> relational database. If not, the script returns non-zero.
>
> 2) A script that probes whether Grouper can connect to ALL of its
> configured subject sources. If not, the script returns non-zero.
>
> Then the entrypoint script for the image could be evolved so that after
> it completes all of its "prep" work, but before exec'ing to become one
> of the Grouper services (ui, ws, daemon, ...), it runs the first script
> and loops until it returns zero (with a sleep interval in between and
> logging to stdout "Unable to connect to database, sleeping...."). Once
> the first script is executed successfully then it would do the same
> thing with the second script. Once that script returns successfully it
> would then exec.
>
> This change should not adversely impact deployers using external
> "enterprise" database and subject source services that not are part of
> the Grouper orchestration since the probes should return quickly. It
> might even help more readily diagnose issues during startup if those
> enterprise services happen to be down.
>
> Thoughts?
>
> Scott K
>
> P.S. It may be that (1) and (2) can be accomplished together in a single
> simple GSH script--I don't know enough about how Grouper initializes
> itself when spinning up GSH.