Skip to Content.
Sympa Menu

grouper-users - [grouper-users] proposed enhancement to TAP Grouper Docker image

Subject: Grouper Users - Open Discussion List

List archive

[grouper-users] proposed enhancement to TAP Grouper Docker image


Chronological Thread 
  • From: Scott Koranda <>
  • To: grouper-users <>
  • Subject: [grouper-users] proposed enhancement to TAP Grouper Docker image
  • Date: Sat, 8 Jun 2019 09:14:04 -0500

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.



Archive powered by MHonArc 2.6.19.

Top of Page