Richard Jones | Erlang rebar tutorial: generating releases and upgrades

[RJ]

Written on 03/30/2011 14:18:50

URL: http://www.metabrew.com/article/erlang-rebar-tutorial-generating-releases-upgrades

[RJ]

Comment written by Steven Gravell on 03/31/2011 14:01:53

Covers everything I was gonna write about, so guess there's no point now :p great job! This'll be the de-facto search results for this stuff soon

[RJ]

Comment written by Per Melin on 04/01/2011 11:33:32

Regarding going back to the first version; even if there wasn't the issue of start.boot that you point out, it wouldn't work. You need to add a step to your workflow for that.

If you look in releases/RELEASES after the first upgrade you will see this at the end: {release,"dummynode","1",undefined,[],permanent}. Unfortunately that fourth element that is undefined should actually be the ERTS version, and the fifth element should be a list of paths to your code. Trying to make this release version permanent again would not work.

I've found that when you set up a first target system you must call release_handler:create_RELEASES/4 on it. Not only that, you must restart the emulator afterward. This step seems like it could've easily been avoided in release_handler.

[RJ]

Comment written by Andrey Smirnov on 04/12/2011 13:43:18

I'm having trouble generating upgrade.
andrey@andrey-desktop:~/src/dummy_proj$ ./rebar generate-upgrade previous_release=dummynode_first
==> rel (generate-upgrade)
ERROR: Systools aborted with: [{error_reading,
{dummy_proj,{not_found,"dummy_proj.app"}}}]
but
andrey@andrey-desktop:~/src/dummy_proj$ ls /home/andrey/src/dummy_proj/apps/dummy_proj/ebin
dummy_proj.app dummy_proj.beam dummy_proj_sup.beam
dummy_proj.appup dummy_proj_server.beam

Thanks

[RJ]

Comment written by metabrew on 04/12/2011 14:16:52

I think generate-upgrade reads the release from rel/, not your apps dir.
Make sure you've run "./rebar generate" so you have a rel/dummynode as well as rel/dummynode_first, then try generate-upgrade again.

[RJ]

Comment written by Andrey Smirnov on 04/14/2011 06:15:28

Thanks for the reply, but unfortunately I can't generate upgrade.
From wiki(https://github.com/basho/re... Appup and upgrade generation do not work with zipped applications (.ez extension), but "./rebar generate" creates a zipped version of it!

After unpacking, execute the command "./rebar generate-upgrade previous_release=dummynode_first", but I get the following error:
andrey@andrey-desktop:~/src$ ./rebar generate-upgrade previous_release=dummynode_first

==> rel (generate-upgrade)
rel (generate-upgrade)
ERROR: Systools aborted with: [{error_reading,
{dummy_proj,
{no_valid_version,
{{"should be","1"},
{"found file",
"./dummynode/lib/dummy_proj-2/ebin/dummy_proj.app",
"2"}}}}}]

[RJ]

Comment written by metabrew on 04/14/2011 06:20:03

You can add this to your rel/reltool.config: {excl_archive_filters, [".*"]},
If you do that, ./rebar generate won't create any .ez files.

[RJ]

Comment written by Andrey Smirnov on 04/14/2011 09:08:50

Thanks, appups works, but for "./rebar generate-upgrade previous_release=dummynode_first" error remained.

andrey@andrey-desktop:~/src$ ./rebar generate-appups previous_release=dummynode_first
==> rel (generate-appups)
Appup generation complete
andrey@andrey-desktop:~/src$ cat ./rel/dummynode/lib/dummy_proj-2/ebin/dummy_proj.appup
{"2",
%% Upgrade instructions from 1 to 2
[{"1", [
{load_module, dummy_proj_server}
]}],
%% Downgrade instructions from 2 to 1
[{"1",[
{load_module, dummy_proj_server}
]}]
}.
andrey@andrey-desktop:~/src$ ./rebar generate -f
==> rel (generate)
andrey@andrey-desktop:~/src$ ./rebar generate-upgrade previous_release=dummynode_first
==> rel (generate-upgrade)
ERROR: Systools aborted with: [{error_reading,
{dummy_proj,
{no_valid_version,
{{"should be","1"},
{"found file",
"./dummynode/lib/dummy_proj-2/ebin/dummy_proj.app",
"2"}}}}}]
dummy_proj.app:
{application,dummy_proj,
[{description,[]},
{vsn,"2"},
{registered,[]},
{applications,[kernel,stdlib]},
{mod,{dummy_proj,[]}},
{env,[]},
{modules,[dummy_proj,dummy_proj_server,dummy_proj_sup]}]}.

[RJ]

Comment written by metabrew on 04/14/2011 09:12:29

looks like your v2 exists ok, (rel/dummynode).
does rel/dummynode_first exist, with a lib/dummy_proj-1/ebin/dummy_proj.app that specifies version 1? If not you will need checkout the v1 branch and generate it again, then move it to rel/dummynode_first

[RJ]

Comment written by Andrey Smirnov on 04/14/2011 10:55:29

Thank you very much, now it works! (dummy_proj-1 was dummy_proj-1.ez).

[RJ]

Comment written by Bart van deenen on 05/06/2011 14:43:34

THANKS!

Your tutorial provides a clear explanation of the rebar application build and upgrade concepts.

It took me a while to get it working, since the text of your tutorial doesn't exactly match the code on github, but as often, it's figuring out where it goes wrong that makes you really understand it. I had problems similar to Andrey Smirnov.

[RJ]

Comment written by Harsh on 06/05/2011 19:50:08

Please fix the typo of "rebar.conf" to "rebar.config". Misleads a beginner (for whom this tutorial may seem intended for) :)

[RJ]

Comment written by Daniel Abrahamsson on 06/08/2011 08:14:51

Lots of thanks for this article! Saved me some headache.

[RJ]

Comment written by robertmeta on 08/09/2011 20:01:13

Exceptional write-up, thanks for shedding some light on a topic that often feels like a bit of a blackhole. One thing I am curious about, how often are you doing proper full releases compared to a series of cowboy changes?

[RJ]

Comment written by metabrew on 09/05/2011 20:35:13

I'm doing full releases as infrequently as I can get away with, because they are stressful and time-consuming :)

They are essential when you need to change state, modify records, mess with supervisors etc.. Kinda depends on your app as to how often you need to do things like that.

[RJ]

Comment written by Roman Janusz on 09/07/2011 18:40:08

I have some serious problems running the release. When I invoke "bin/somenode console", this is what I get:

Exec: /home/ghik/Inz/somerel/rel/somenode/erts-5.8.4/bin/erlexec -boot /home/ghik/Inz/somerel/rel/somenode/releases/1/somenode -mode embedded -config /home/ghik/Inz/somerel/rel/somenode/etc/app.config -args_file /home/ghik/Inz/somerel/rel/somenode/etc/vm.args -- console
Root: /home/ghik/Inz/somerel/rel/somenode
{"init terminating in do_boot",{'cannot load',hipe_adj_list,get_files}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()

My system is Ubuntu 11.04 64bit, erlang R14B03 (from sources).
I posted this on stackoverflow, too: http://stackoverflow.com/qu...
I would be really grateful for some help with that...

[RJ]

Comment written by metabrew on 09/07/2011 22:33:06

Unless you are sure you need HIPE, which you probably don't, then it's best to avoid it.
I don't know exactly why, but most people end up hitting hipe-related problems when building releases.

I always build erlang without hipe, and subsequently don't encounter these problems any more.

I strongly recommend removing hipe from your erlang install (i think it's safe to just remove the hipe-A.B.C dir) and then doing a clean "rebar generate" and starting the process again.

[RJ]

Comment written by f3r3nc on 12/05/2011 19:12:08

This post is great, BUT the github code / code listings difference IS confusing. Also rebar changed a bit and it needs a sys.config. (Create-node will make it just fine, however) app.conf will make it crash at the generate-upgrade part  (rebar version: 2 date: 20111205_155958 vcs: git 54259c5) thus the code from the github is not working. 
Anyway, just made my first hot code swap based on this blog. #epic

[RJ]

Comment written by Ley Atraccion on 01/19/2012 02:50:13

thanks a lot for this great tutorial....its really useful now i generate relases faster..!!!!
my best wishes!!   motivación
personal

[RJ]

Comment written by Guest on 03/06/2012 04:56:14

the all above steps don't work at all.   after you create  "
create-app appid=dummy_proj", there is no such sub-directory(dummy_proj) under apps as you needed in rebar.conf. in addition, it is rebar.config, not rebar.conf. too many error in the blog, I had to say. It is a good post but too many errors.

[RJ]

Comment written by escorte on 03/20/2012 16:36:12

As a contractor, I address some of these issues are a regular basis thanks for making sense!

[RJ]

Comment written by InfoSec812 on 03/29/2012 05:32:01

If anyone else is following this tutorial and getting errors when trying to do a "rebar generate-upgrade" which look something like:

# rebar generate-upgrade previous_release=redns_1
==> rel (generate-upgrade)
ERROR: Systools [systools:make_relup/4] aborted with: [{error_reading,
                                                        {mnesia,
                                                         {{bad_param,
                                                           start_phases},
                                                          {application,
                                                           mnesia,
                                                           [{description,
                                                             "MNESIA  CXC 138 12"},
                                                            {vsn,"4.6"},
                                                            {id,[]}, . . . . . [snip]

The problem is detailed at http://erlang.org/pipermail...

And can be fixed by locating every ".app" file in BOTH releases and removing the "{start_phases, undefined}," lines from each. After removing that line, you can run the generate-upgrade successfully.

[RJ]

Comment written by rebar tier on 03/30/2012 09:20:34

The TURBO TIE is super-fast, light weight and compact. Just
pull the trigger and the TURBO TIE a tie rebar in one second and is 5 x's
faster than manual tying. This simple operation reduces potential wrist damage
such as carpal tunnel injuries. Using the optional extension bar reduces the
risk of back injuries.
 

[RJ]

Comment written by rebar tier on 03/31/2012 08:35:43

The TURBO TIE is super-fast, light weight and compact. Just
pull the trigger and the TURBO TIE a tie rebar in one second and is 5 x's
faster than manual tying. This simple operation reduces potential wrist damage
such as carpal tunnel injuries. Using the optional extension bar reduces the
risk of back injuries.

[RJ]

Comment written by Pascalchap on 03/12/2013 14:05:00

Thank you for this post.
Very useful as long as the rebar tool is nice, and the rebar doc... where did I store the rebar doc?

[Gaurdeepak]

/home/rel/ejabberd/erts-7.3/bin/erl: line 34: /home/rel/ejabberd/erts-7.3: is a directory

/home/rel/ejabberd/erts-7.3/bin/erl: line 34: exec: /home/rel/ejabberd/erts-7.3: cannot execute: Success

Getting this when run any command, I think erts/erl is not worrking. Can any one help.

[Gaurdeepak]

After calling generate-upgrade getting this crash Command: ./rebar generate-upgrade previous_release=ejabberd_1

Crash: ERROR: 'generate-upgrade' failed while processing /home/ejabberd_development_copy/ejabberd_app/rel: {'EXIT',{{badmatch,{error,enoent}}, [{rebar_upgrade,boot_files,3, [{file,"src/rebar_upgrade.erl"},{line,177}]}, {rebar_upgrade,'generate-upgrade',2, [{file,"src/rebar_upgrade.erl"},{line,66}]}, {rebar_core,run_modules,4,[{file,"src/rebar_core.erl"},{line,405}]}, {rebar_core,execute,5,[{file,"src/rebar_core.erl"},{line,334}]}, {rebar_core,process_dir1,6,[{file,"src/rebar_core.erl"},{line,197}]}, {rebar_core,process_each,5,[{file,"src/rebar_core.erl"},{line,268}]}, {rebar_core,process_dir1,6,[{file,"src/rebar_core.erl"},{line,173}]}, {rebar_core,process_commands,2, [{file,"src/rebar_core.erl"},{line,61}]}]}}