josevalim
commented
5 years ago Hi folks,
I have spent most of the week studying hot code upgrades and building prototypes and I have decided to not include them as part of Elixir Core for now (at least for Elixir v1.9). The rationale is that they are still very complex, error prone and opinionated in a way that whoever is performing them needs to be aware of many of the decisions taken. For example, the distillery guides on appups (which is a part of hot code upgrades) covers many of those topics.
We are not saying they will never be part of Elixir but not for now. This can be a good opportunity for the community to build on top of what Elixir provides.
I wrote an extensive section on the docs about hot code upgrades which I reproduce below for convenience that explains this rationale and guides users.
Erlang and Elixir are sometimes known for the capability of upgrading a node that is running in production without shutting down that node. However, this feature is not supported out of the box by Elixir releases.
The reason we don't provide hot code upgrades is because they are very complicated to perform in practice, as they require careful coding of your processes and applications as well as extensive testing. Given most teams can use other techniques that are language agnostic to upgrade their systems, such as Blue/Green deployments, Canary deployments, Rolling deployments, and others, hot upgrades are rarely a viable option. Let's understand why.
In a hot code upgrade, you want to update a node from version A to
version B. To do so, the first step is to write recipes for every application
that changed between those two releases, telling exactly how the application
changed between versions, those recipes are called .appup files.
While some of the steps in building .appup files can be automated,
not all of them can. Furthermore, each process in the application needs
to be explicitly coded with hot code upgrades in mind. Let's see an example.
Imagine your application has a counter process as a GenServer:
defmodule Counter do
use GenServer
def start_link(_) do
GenServer.start_link(__MODULE__, :ok, name: __MODULE__)
end
def bump do
GenServer.call(__MODULE__, :bump)
end
## Callbacks
def init(:ok) do
{:ok, 0}
end
def handle_call(:bump, counter) do
{:reply, :ok, counter + 1}
end
endYou add this process as part of your supervision tree and ship version
0.1.0 of your system. Now let's imagine that on version 0.2.0 you added
two changes: instead of bump/0, that always increments the counter by
one, you introduce bump/1 that passes the exact value to bump the
counter. You also change the state, because you want to store the maximum
bump value:
defmodule Counter do
use GenServer
def start_link(_) do
GenServer.start_link(__MODULE__, :ok, name: __MODULE__)
end
def bump(by) do
GenServer.call(__MODULE__, {:bump, by})
end
## Callbacks
def init(:ok) do
{:ok, {0, 0}}
end
def handle_call({:bump, by}, {counter, max}) do
{:reply, :ok, {counter + by, max(max, by)}}
end
endIf you to perform a hot code upgrade in such application, it would
crash, because in the initial version the state was just a counter
but in the new version the state is a tuple. Furthermore, you changed
the format of the call message from :bump to {:bump, by} and
the process may have both old and new messages temporarily mixed, so
we need to handle both. The final version would be:
defmodule Counter do
use GenServer
def start_link(_) do
GenServer.start_link(__MODULE__, :ok, name: __MODULE__)
end
def bump(by) do
GenServer.call(__MODULE__, {:bump, by})
end
## Callbacks
def init(:ok) do
{:ok, {0, 0}}
end
def handle_call(:bump, {counter, max}) do
{:reply, :ok, {counter + 1, max(max, 1)}}
end
def handle_call({:bump, by}, {counter, max}) do
{:reply, :ok, {counter + by, max(max, by)}}
end
def code_change(_, counter, _) do
{:ok, {counter, 0}}
end
endNow you can proceed to list this process in the .appup file and
hot code upgrade it. This is one of the many steps one necessary
to perform hot code upgrades and it must be taken into account by
every process and application being upgraded in the system.
The .appup cookbook
provides a good reference and more examples.
Once .appups are created, the next step is to create a .relup
file with all instructions necessary to update the release itself.
Erlang documentation does provide a chapter on
Creating and Upgrading a Target System.
Learn You Some Erlang has a chapter on hot code upgrades.
Overall, there are many steps, complexities and assumptions made
during hot code upgrades, which is ultimately why they are not
provided by Elixir out of the box. However, hot code upgrades can
still be achieved by teams who desire to implement those steps
on top of mix release in their projects or as separate libraries.
OvermindDL1
bitwalker
jesseshieh
Gazler
This is a meta issue to track the progress of releases in Elixir. The goal is to include minimum support for releases, then add user conveniences, and then finally work on hot code upgrades with relups and appups.
Milestone 1
The goal here is to add releases to core without many bells and whistles:
mix releasesupport to Elixir (#8677)Milestone 2
The goal here is implement user facing features:
Mix.Config. The default config provider will look a config atconfig_path |> Path.dirname() |> Path.join("release.exs")and always log if a release config is being used or not. We also need to raise a good error message ifMix.Configis used instead ofConfig