[erlang-questions] Upgrades and application environment

[Michael Radford]

This issue bit us again today: someone added an application environment
variable and wrote a code_change handler that (indirectly) read it,
causing the upgrade to crash.

So I'm curious, what strategies do people use in practice for adding new
configuration variables to running systems (at Ericsson, or elsewhere)?
Do they:
	* not use application environment variables at all (keeping
	  configuration somewhere else)?

	* stop and start the whole application on every upgrade?

	* use some trick like I outlined below to wait for config_change?

Mike

I wrote:
> A related question....  This is an issue that often makes me resort to
> stopping and starting my applictions on upgrade, even when it should be
> easy to avoid.
> 
> It seems that release_handler:eval_appup_script/4 first evaluates the
> upgrade script directives (reloads modules, calls code_change handlers,
> etc.), and then afterward changes the application configuration and
> calls config_change.  Perhaps there's a good reason for this order.
> 
> But in any case, this means that if you add a new application
> environment variable controlling some new behavior of a server, it won't
> be available when the server's code_change hander is called.  So the
> obvious way of doing things (in code_change, read the value of the new
> variable and use it to transform the state) will crash.
> 
> Is there an easy way to work around this?
> 
> My only idea was to have code_change put the server into a temporary
> state where it's waiting for the application's config_change handler to
> be called, and then Application:config_change somehow knows about a list
> of gen_servers (etc.) to call with the new configuration.
> 
> Maybe this could be handled generically by an extension to gen_server.
> It would be nice to be able to write
>   code_change (OldVersion, EnvChanged, EnvNew, EnvRemoved, State, Extra)
> and do all the transformations in one place.
> 
> Mike