<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 12, 2013 at 10:09 PM, Geoff Cant <span dir="ltr"><<a href="mailto:nem@erlang.geek.nz" target="_blank">nem@erlang.geek.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We use the OTP application environment for configuration data almost exclusively in the systems we build at Heroku. Logplex ( <a href="https://github.com/heroku/logplex" target="_blank">https://github.com/heroku/logplex</a> ) is an example of one of these. We do a few things to make it more usable for us.<br>
<br>
* application:get_env(my_app, key). is really fast - it's just an ETS read, so do it pretty much everywhere except in a tight loop. -- <a href="https://github.com/heroku/logplex/blob/master/src/logplex_message.erl#L73" target="_blank">https://github.com/heroku/logplex/blob/master/src/logplex_message.erl#L73</a><br>
* This means your app automatically pick up and use changes in this configuration.<br>
* If you have a tcp listener, don't pass its Port configuration via supervisor start arguments, have the init routine for the listener read application:get_env -- <a href="https://github.com/heroku/logplex/blob/master/src/tcp_acceptor.erl#L57" target="_blank">https://github.com/heroku/logplex/blob/master/src/tcp_acceptor.erl#L57</a><br>
* This allows you to update the app_env config and then apply it by doing a terminate_child and restart_child on the listener process from the supervisor.<br>
* If you read configuration from the unix environment into your OTP app environment, maybe use a library to make that less painful. <a href="https://github.com/heroku/logplex/blob/master/src/logplex_app.erl#L84" target="_blank">https://github.com/heroku/logplex/blob/master/src/logplex_app.erl#L84</a> and <a href="https://github.com/heroku/stillir" target="_blank">https://github.com/heroku/stillir</a><br>
<br>
When we used to cache configuration all over the place in gen_server state and supervisor child specs, updating the configuration was really difficult. Now that we avoid that, we find the OTP app env really good for configuration data and like the centralised storage in ETS, the ability to inspect it with get_all_env, quick updates and all the support for -app env_key env_value, -config <file>.config and so on.<br>
<br>
Cheers,<br>
--<br>
Geoff Cant<br></blockquote><div><br></div><div><br></div><div>Sorry for the late answer. Thanks for the useful information and links, stillir was the bit I was missing. With that your method and the one proposed by Max Lapshin I think I will be able to do something. It will reduce a little the number of conf levels I need. </div>
<div><br></div><div>The last thing I need to figure is to find a way to mix that with cuttlefish (<a href="https://github.com/basho/cuttlefish">https://github.com/basho/cuttlefish</a>) so the end user will have a human friendly configuration file (or sort of).</div>
<div><br></div><div>- benoit</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div class="h5">
On 2013-11-12, at 02:17 , Ignas Vyšniauskas <<a href="mailto:baliulia@gmail.com">baliulia@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> I've too struggled with this problem quite a few times.<br>
><br>
> One thing I never got to try out: What about pushing relups with only<br>
> configuration data changed? Then you get versioning for free, you can<br>
> also specify how each application should deal with the new configuration<br>
> data (just update it / stop / restart gen_servers, etc).<br>
><br>
> You get all the release goodies and would basically just need to write<br>
> some scripts to generate "light" relups.<br>
><br>
> Your application's would also need to have a proper `config_changed/2`<br>
> callback, but this IMHO is much nicer than rolling your own thing.<br>
><br>
> If you are doing releases and relups already (and you should!) then this<br>
> seems like a decent path to follow.<br>
><br>
> --<br>
> Ignas<br>
</div></div>> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>