Multiple errors when trying to do a basic release with Distillery. Is it OTP 26 compatible?

Questions / Help
,
1

I’ve been working through Programming Elixir, the second half of Chapter 20 pertains to releases and hotcode reloading.

One of the first errors I experienced was when using mix release --env=prod

Mix could not invoke task “release” : 1 error found
–env :unknown option

When I found that the new mix format to be used for distillery was distillery., I started again (after cleaning) using distillery.init, then distillery.release --env=prod.

Everything was beginning to build then I got a Release Failed error regarding not finding a file at ./config/config.exs, which is a bit odd because it’s my first time using distillery so I’m taking the out of the box approach, and copying files directly into config is not recommended by the distillery guides.

Throwing more at the problem I updated my dep description of distillery to include github: "bitwalker/distillery", in case github was ahead of the pm.

deps do
  [
    {:distillery, "~> 2.1", runtime: false,  github: "bitwalker/distillery"}
  ]
end

runtime: false was removed, but I understand it is ignored anyway.

After I relented and touched config/config.exs I got to the packaging stage of distillery.release before triggering a Failed to archive release error that no such file or directory was located at the target uri (stipulated in the error log).

Does distillery work on the latest OTP?

I’ve been looking around and haven’t found much info regarding these bugs other than that there was a breaking change in erlang/otp 25. I’m using Erlang/OTP 26. I’ve not seen notice of a rectification.

I downloaded OTP 24 but I am reluctant to switch to it for the sake of completing this example.

Moved to chapter 21 for the time being so this isn’t necessarily urgent, just a request for clarification.

Much appreciated.

2

Distillery was used back in the day, I am not sure it is still actively supported.

The official way to make releases now is to use releases. You can do that from any elixir project by running release task:

mix release
2 Likes
3

Thanks a lot. Is the architecture for hotcode reloading now built in or does it require a library?

I don’t yet have plans for using such a feature I’m asking for future reference.

4

No idea to be fair, we don’t dabble with such things in our production systems.

1 Like
5

Currently releases do not support hot code upgrades.

2 Likes
6

They do not come with tools to handle hot code updates, but libraries like Castle - Hot-Code Upgrade Support for Elixir can plug that into the release building.

7

The architecture for hot reloads exists at the erlang level (in the form of AppUps) but it is rarely used in prod (at least in my experience, I’m sure Ericsson would beg to differ) because there are a few annoying caveats.

We used to use them at Appcues, but it ended up being more of a pain than it was worth, so now we just reboot the processes. This gives us a few other useful properties (clearing ETS caches, not needing to coordinate running process version upgrades) and is easier for us to reason about.

To directly answer your question, distillery doesn’t currently support OTP 25 (see also; THIS LIBRARY IS NOT COMPATIBLE WITH ERLANG/OTP 25 · Issue #744 · bitwalker/distillery · GitHub) but there is a fix on a fork, YMMV.

2 Likes
8

Imagine you are talking on the phone and your call stops because someone did a new deploy :smile: . In their case that feature was crucial and maybe once we can create a good abstraction over it, we will harness the full power without these nitty-gritty details.

2 Likes
9

Yes, and that’s absolutely the case I was thinking of :joy:

It’s a nice to have, for sure! The industry I work in (SaaS software), we use Channels, and it’s not a problem for us to just reboot the servers, because the websocket will reconnect to an alive, not-being-deployed server, and I don’t need to worry if whoever wrote the appup remembered to start the new Supervisor or whatever, we just start at the state we want via application.ex and don’t worry about it.

The downside is, we need to deploy our service one (or a small few) at a time, because if we deploy, say, all the servers (~50+ m6g.8xl on a heavy day) at once, we would have downtime, as well as the dread thundering herd as millions of websockets reconnect and resume state.

We used to use hot upgrades, but the mental burden on the engineers of figuring out “can I do this hot or does it need to be a release” became too much of a headache. Still, it was nice to be able to deploy all of our servers at once (currently takes ~30 mins to deploy the fleet)

2 Likes
10

Damn, that is a lot of computing power.

In this case, I agree that having hot-code reload is pretty neat. I think that once I will have some time to spare, I will start exploring this, as I think it might be a great feature if ironed out properly.