Deployment tools?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Deployment tools?

Dustin Sallings

        I've got an application deployed in a two-node cluster that does
environmental monitoring in my house.  I currently have two problems
that I believe have simple solutions, but I'm not quite getting what
needs to happen for this:

        1) Dynamic code redeployment.

                I'd like to be able to make a change and get it applied on my nodes.  
I've played with spawn + the code module, but I'd like to actually get
some confirmation somewhere (log, or better, the console from which I
issue deployment).  I also don't quite understand purging.  Most
ideally, this would be something I could use in my build environment to
update the code across the network, but I'd like to make sure that if
the application gets completely restarted on a given node, it's running
the latest code.

        2) Dynamic reconfiguration.

                This is similar to the above, and I've actually done it, but it was
more work than I'd think I'd need to make.  A lot of my monitoring
parameters are in my .app config (device aliases, operating range,
maximum amount of time I can go without hearing from a device,
notification lists, etc...).


        Currently, I go to the nodes and just restart the apps.  Doing so is
just a little inconvenient, but also causes me to lose a little state.  
If a sensor is in an alarming state, I want to avoid sending an alarm
for a certain period of time, which is state that's kept on the stack.

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________



Reply | Threaded
Open this post in threaded view
|

Deployment tools?

Martin J. Logan
<snip>
>
> 2) Dynamic reconfiguration.

This one is not as simple as it seems. First of all your code must be
written in such a manner as to allow a altered config to make its way
into process state.

cant have

init() ->
    Blah = application:get_env(blah, blah),
    {ok, #state{blah = blah}}.


but instead you must use get_env everywhere blah is referenced or have a
clean way of HUPing the processes to re-read config and update state.
Whatever way you choose it sill necessitate some stylistic changes.

The solution that a few colleagues and I came up with was to wrap
configuration with another api and include that api as part of a generic
services application included in every release.

<wrapper>:get_env(Application,  Key, DefaultValue)

Then wrapper functions first referenced a central configuration
repository. This repository saved configuration for all apps on the
system and was capable of being updated at anytime. When an application
configuration was updated all or some subset of all apps would receive
the update based on manager discression.

This was a great system in theory but for whatever reason never quite
made it in production. This is perhaps because "wasting time on that
uhrlang or airplane, whatever, language no one knows" was frowned upon
in that environment )-:
 


>
> This is similar to the above, and I've actually done it, but it was
> more work than I'd think I'd need to make.  A lot of my monitoring
> parameters are in my .app config (device aliases, operating range,
> maximum amount of time I can go without hearing from a device,
> notification lists, etc...).
>
>
> Currently, I go to the nodes and just restart the apps.  Doing so is
> just a little inconvenient, but also causes me to lose a little state.  
> If a sensor is in an alarming state, I want to avoid sending an alarm
> for a certain period of time, which is state that's kept on the stack.
>
> --
> SPY                      My girlfriend asked me which one I like better.
> pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin>
> |    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
> L_______________________ I hope the answer won't upset her. ____________



Reply | Threaded
Open this post in threaded view
|

Deployment tools?

Hal Snyder-2
"Martin J. Logan" <mlogan> writes:

> <snip>
>>
>> 2) Dynamic reconfiguration.
>
> This one is not as simple as it seems. First of all your code must be
> written in such a manner as to allow a altered config to make its way
> into process state.
>
> cant have
>
> init() ->
>     Blah = application:get_env(blah, blah),
>     {ok, #state{blah = blah}}.
>
>
> but instead you must use get_env everywhere blah is referenced or have a
> clean way of HUPing the processes to re-read config and update state.
> Whatever way you choose it sill necessitate some stylistic changes.
>
> The solution that a few colleagues and I came up with was to wrap
> configuration with another api and include that api as part of a generic
> services application included in every release.
>
> <wrapper>:get_env(Application,  Key, DefaultValue)

You could also base things on e.g. the approach Joe offers for a
universal Client - Server with hot code swapping at
http://www.sics.se/~joe/talks/ll2_2002.pdf, page 20.


server(Fun, Data) ->
  receive
    {new_fun, Fun1} ->
      server(Fun1, Data);
    {rpc, From, ReplyAs, Q} ->
      {Reply, Data1} = Fun(Q, Data),
      From ! {ReplyAs, Reply},
      server(Fun, Data1) end.

rpc(A, B) ->
  Tag = new_ref(),
  A ! {rpc, self(), Tag, B},
  receive
    {Tag, Val} -> Val
  end.