[erlang-questions] pattern to augment a release with a plugin system

[zxq9]

On 2015年11月30日 月曜日 04:43:56 Benoit Chesneau wrote:
> On Sun, Nov 29, 2015 at 11:49 PM Michael Truog <mjtruog@REDACTED> wrote:
> 
> > Having Erlang applications started and stopped dynamically can be contrary
> > to having the system fail-fast.  So, that is a danger, since you are not
> > always starting from a known starting state, the dynamic actions are
> > dealing with state that is unknown due to the point in time during the
> > runtime when the actions execute.  There is only one boot file which the
> > Erlang VM accepts on its command line, and that contains the list of
> > actions which are suppose to provide a successful startup of the release,
> > and if not, it should crash due to validation during initialization.
> >
> >
> Right. then maybe "plugins"  in Erlang world should be seen as a way to
> augment a release from binary packages and provide some tooling around to
> make the experience easy for non Erlang users.
> 
> Another way could be sending remotely the packages and regenerate locally
> the boot script. Not sure how crazy it is. I can see the possible
> uncertainty on reboot if any problem happen during a deployment it can
> creates though. But how much it would be different from a bad release
> upgrade?

One way it differes: you expect a reboot, you don't expect a relup failure.

The circus that necessarily surrounds trying to make plugins work with releases is one reason why (for client-side code where we need plugins) we release signed source bundles, have clients checkupdate/build on execution, and execute from the file system the way other language runtimes tend to. We're not deploying to telecom switches or industrial controllers, and we aren't expecting live upgrades to work.

Note, that is for *client* side code -- a pretty uncommon use case across Erlangdom. I have a hard time seeing the advantage of a server-side dynamic plugin system based on releases that isn't distributed as a configurable bundle of source ([config plugins] && [run release building tool]). The hardest part of relups is making sure it won't break anything.

It seems like it would require either some very strict coding conventions (and version control) or some very exhaustive live integration testing to determine whether or not a relup from R1{P1, P2} to R2{P1, P2, P3} would work, not to mention the case of R1{P1, P2} to R2{P2, P3}. The amount of work involved in that would probably squash any benefits of even having a plugin system, not to mention make a rolling upgrade look easy in comparison to a relup. You would either need a fancy version numbering system or a local way of tracking version numbers, too... hrm.

Releases don't seem very plugin-friendly. What am I missing?

-Craig