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

[Michael Truog]

On 11/26/2015 02:37 AM, Benoit Chesneau wrote:
> Hi all,
>
> I am actually working on a system to augment a release possibly dynamically with some extensions.
>
> For now in hooks [1] I am starting applications from the filesystem or just using the applications shipped with the release. I am not a fan of simply starting/stopping applications from the filesystem since for now it is not handling upgrades (only by starting/stopping the application) like a release can do.
>
> I can see these different ways to handle plugins right now:
>
> 1) plugins are only added at compile time (something rabbitmq does). Similar to 1
>
> pro: plugins are the simple apps
> cons:
> - the system is not dynamic and a user can't simply augment the application he is using. Only plugins built and shipped with the release are available
>
> 2) adding plugins to a release and possibly starting them when enabled via the config. The upgrade would be done via a release upgrade.
>
> Pro:
> - doesn't change too much the current way to handle releases upgrade.
> - the plugins can be added dynamically
>
> Cons:
> - if i want to add a new plugin I will need to create a new release, increment its version etc.
> - Also a new release would have to be build for each users depending on their choice.
> - I have to find a way to build a local release based on remote plugins depending on the platform
>
> 3) load plugins via an external system. If this is an apps, it will be installed using the release_handler, so it could possibly manage  the .appup scripts
>
> pro: plugins are really dynamically handled
>
> cons:
> - not sure on how with the release_handler the installed application will be handled at startup.
> - not sure if dynamically augmented release using the release_handler is suppored
>
> 4) Something similar to 3 , but instead of using the release_handler, i have my own plugin_handler handling upgrades by looking on specific modules functions if needed.
>
> Are there other ways to do it? What would be the right pattern to do it? To be honest I am balancing between 2 and 3. 4 would be fine but would mean rewriting something similar to the release_handler.
>
> Generally speaking how people feels about augmenting dynamically a release with new applications/modules ?
>
> Any feedback is welcome.
>
> - benoît
>
>
> [1] https://github.com/barrel-db/hooks
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
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.

However, it is helpful to be able to dynamically start and stop Erlang applications, if the system has dynamic functionality it needs to support (hopefully with careful validation in isolation, so it doesn't cause instability).  I have functions for this at https://github.com/okeuday/reltool_util .  You might like reltool_util:application_remove/3 since that handles dependencies too, if they aren't shared with other applications.  I prefer reltool_util:application_start/3 instead of application:ensure_started/1 since it handles module loading too. The reltool_util module also contains functions for handling release boot and script files.

Best Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151129/2e3b3ec8/attachment.htm>