Failfast / don't fail starting

[Christopher Bongaarts]

On 12/2/2013 2:20 PM, Paul Hethmon wrote:
> As a deployer, I like the fail fast. If I give Shib some garbage, it stops
> and I know it right then instead of later when I'm asleep and the customer
> calls me to complain.

Apologies for the late reply, and also if this has been answered (I've 
not been able to keep up with all the IdP3 threads):

My biggest issue with the fail-fast has been treating what are arguably 
operational failures (can't reach LDAP server) as config failures.

The main "use case" (or maybe better termed "gripe about idp2") is a 
situation where you have shut down your LDAP and IdP servers (say, for 
yearly data center maintenance), and the IdP starts up faster than the 
LDAP service.  Ideal behavior: IdP begins startup, but fails requests 
involving LDAP until a working connection is established.  Current 
behavior:  IdP explodes violently and must be restarted by hand.

In my case, we treat the attribute resolver config as reloadable, so 
Rod's case of "start the refresh thread" would probably cover this for 
us, but I question whether treating that as a configuration failure even 
makes sense to begin with.

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%