Cannot use relx built relups to upgrade a running system. about relx

[tsloughter]

Ah, yeah, I had to grab the newest. Then I got it working by making:

[/tmp/beat/releases/0.1.1] $ ls
beat.tar.gz  beat.rel

Then in the console:

> release_handler:unpack_release("0.1.1/beat").

Main thing to take away is that it is releases/0.1.1 as the directory and the beat.rel file for 0.1.1 is in that directory along with the tar.gz.

I didn't think that should be necessary... So I'll have to do some more research to understand how we can make this better in relx.

If you get it working based on this let me know if you have suggestions on making it better.

[blt]

I still haven't got it working, I'm afraid. Here's the new version of v1to2.sh:

#!/bin/sh                                                                               

set -e

rm -rf /tmp/beat
rm -rf _rel

git checkout v1
make release
tar cvzf beat-0.1.0.tar.gz -C _rel .

git checkout v2
make relup
tar cvzf beat-0.1.1.tar.gz -C _rel .

mkdir -p /tmp/beat
cp _rel/releases/beat-0.1.1/beat.rel /tmp/
cp beat-0.1.0.tar.gz /tmp
cp beat-0.1.1.tar.gz /tmp

cd /tmp/beat
tar xf /tmp/beat-0.1.0.tar.gz
./bin/beat-0.1.0 start

mkdir releases/beat-0.1.1
cp /tmp/beat-0.1.1.tar.gz releases/beat-0.1.1/
cp /tmp/beat.rel releases/beat-0.1.1/beat-0.1.1.rel # RB15 unpack_release seems to expect this to have APP-VSN name

rm /tmp/beat.rel
rm /tmp/beat-0.1.0.tar.gz
rm /tmp/beat-0.1.1.tar.gz

The updates are around the movement of beat.rel into releases/beat-0.1.1. I noticed in your text the application name was missing--you referred to just 0.1.1--but I'm not sure if that was shorthand or not. My local copy of relx--commit eb6a468--creates releases with the application name.

Anyway, after running the new v1to2.sh I find:

> ./bin/beat-0.1.0 ping
Node '[email protected]' not responding to pings.

> ./bin/beat-0.1.0 start

> ls releases/beat-0.1.1 
beat-0.1.1.tar.gz beat.rel

> ./bin/beat-0.1.0 attach
Attaching to /tmp//tmp/beat/releases/beat-0.1.0/erlang.pipe.1 (^D to exit)

([email protected])1> release_handler:unpack_release("beat-0.1.1/beat-0.1.1").
{error,{enoent,"/tmp/beat/releases/0.1.1/beat-0.1.1.rel"}}

The Directory Structure of the release_handler user guide does say that releases should have the format VSN and not APP-VSN so I guess that's not unexpected. Indeed:

> mv releases/beat-0.1.1 releases/0.1.1

(walden) /tmp/beat
blt> ./bin/beat-0.1.0 attachAttaching to /tmp//tmp/beat/releases/beat-0.1.0/erlang.pipe.1 (^D to exit)

([email protected])6> release_handler:unpack_release("0.1.1/beat-0.1.1").     
{ok,"0.1.1"}

([email protected])7> release_handler:which_releases().
[{"beat","0.1.1",
  ["kernel-2.15.3","stdlib-1.18.3","beat_core-2013.2",
   "ranch-0.8.5","beat_tcp_api-2013.1","sasl-2.2.1"],
  unpacked},
 {"beat","0.1.0",[],permanent}]
([email protected])8> release_handler:in
init/1             install_file/2     install_release/1  install_release/2  

([email protected])8> release_handler:install_release("0.1.1").
{error,{enoent,"/tmp/beat/releases/0.1.0/relup"}}

The relup is actually in the root of the directory. My first inclination was to move releases/beat-0.1.0 to releases/0.1.0 but that will break the extended start script that relx ships out. Instead:

> cp -r releases/beat-0.1.0 releases/0.1.0

>  mv relup releases/0.1.0

> ./bin/beat-0.1.0 attach          
Attaching to /tmp//tmp/beat/releases/beat-0.1.0/erlang.pipe.1 (^D to exit)

([email protected])9> release_handler:install_release("0.1.1").
{error,{bad_relup_file,"/tmp/beat/releases/0.1.0/relup"}}

At this point I'm just stuck and don't know what more to do.

---

relx has been really great for building releases but I haven't yet seen how to go from running relx relup to an upgrade on a live system. It seems like:

• _rel/releases/APP-VSN should be _rel/releases/VSN per http://www.erlang.org/doc/design_principles/release_structure.html#id76047,
• the locations relx places files are not the same that release_handler expects
• and an option to build tarballs for deployment would be highly indicated.

For purposes of upgrading I tentatively think version constraints should be mandatory in relx.config as strange things happen if you build a relup without them.

Ideally, relx would fit into the workflow where a user could relx relup, rsync _rel onto node servers and issue the extended start script's upgrade option to live update the running system. That would be really quite slick.

[tsloughter]

Ok, so it worked for me but with name changes:

$ ls 0.1.1                            
beat.rel  beat.relup  relup  start.boot  start.script  sys.config  vm.args

I always forget about the annoying release_handler/systools release structure. Here release_handler wants start.boot and start.script not beat.boot and beat.script.

I don't see why still to this day Erlang should have to assume there is one release type in the releases directory, but that's how it is.

@ericbmerritt any opinion? Easiest solution is changing the naming scheme to match.

[ericbmerritt]

The release handler doesn't actually want start.script and start.boot. It should only want that if it is otherwise not specified. Ie, that is the default.

[ericbmerritt]

The big problem with changing the structure (if I remember correctly) is that we loose the ability to have multiple releases sit side by side. If thats not possible in a standard OTP release then it may not be a major problem. Also if it causes the problems described above it may very well be worth doing.

Since this seems to be a problem just with taring up the release directory, maybe we add a tar provider that tars it up in the correct way?

[tsloughter]

Eric, no, the release_handler wants those files:

> release_handler:install_release("0.1.1").
{error,{no_such_file,"/tmp/beat/releases/0.1.1/start.boot"}}

And I don't see a way to override that.

[tsloughter]

We could simply do it by having the tar functionality modify the paths, but that would be more confusing than useful I think.

Since it is the standard OTP way of doing thing, even though I agree it is annoying, we may want to finally change to it. I know we didn't follow it with sinan or faxien either, but we got away with that because we didn't use release_handler for upgrades ourselves.

To support the community I think it may be wise to just move to the standards structure. Really it just means that if you want a project to build multiple releases you must use separate output directories for each.

[ericbmerritt]

holy crap. how can the release handler be that monumentally stupid? God I hate it when people do stupid stuff.

I agree though, we have to support the standard and thats the least intrusive way to do it.

[tsloughter]

Yea :(. I'll look into doing it today, shouldn't be much work to make the change.

[tsloughter]

Ah, so we do have to use systools:make_tar, it renames .boot to start.boot. Ridiculous. I'll add that command to relx, and I've made the output dir just the version number.

[tsloughter]

I've added a tar command to relx: https://github.com/tsloughter/relx

Simply run as $ relx tar

An issue still remains however. Currently running any command, like relup or tar, will first generate a release and then do either relup generation or create a tarball.

@ericbmerritt I think it should be that if you want to have it create a release first you do $ relx release relup or $ relx release tar. relx on its own will of course still be the same as $ relx release but the others will not make releases and will be chainable.

[tsloughter]

Note: this patch also changes the directory to releases/<vsn>, that is required for this tar stuff to work.

[tsloughter]

On my branch now if you run $ relx tar it will not generate the release first, it is assumed to exist, if you want to do both at once you must do $ relx release tar. $ relx by itself still is synonymous with $ relx release

I have to update the tests before the PR can be merged, assuming @ericbmerritt is ok with the changes.

[tsloughter]

Grr, and the common test suite catches that I broke relup. It thinks the release is undefined with my changes to when it runs relup. I'll probably have to fix in the morning.

[blt]

Thank you so much, @tsloughter! I've checked out your fork with 628f89f as the latest commit. Re-running v1to2.sh I get the following:

> sh v1to2.sh 
... 99 skip a few ...
Resolved beat-0.1.1
Errors generating relup 
    File not found: "./undefined.rel"

Usage: relx [-n <relname>] [-v <relvsn>] [-g <goal>] [-u <upfrom>]
            [-o <output_dir>] [-l <lib_dir>]
            [--disable-default-libs [<disable_default_libs>]]
            [-V [<log_level>]] [-a <override_app>] [-c [<config>]]
            [-r <root_dir>] [*release-specification-file*]

  -n, --relname           Specify the name for the release that will be 
                          generated
  -v, --relvsn            Specify the version for the release
  -g, --goal              Specify a target constraint on the system. These 
                          are usually the OTP
  -u, --upfrom            Only valid with relup target, specify the 
                          release to upgrade from
  -o, --output-dir        The output directory for the release. This is 
                          `./` by default.
  -l, --lib-dir           Additional dirs that should be searched for OTP 
                          Apps
  --disable-default-libs  Disable the default system added lib dirs (means 
                          you must add them all manually [default: false]
  -V, --verbose           Verbosity level, maybe between 0 and 2 [default: 
                          1]
  -a, --override_app      Provide an app name and a directory to override 
                          in the form <appname>:<app directory>
  -c, --config            The path to a config file [default: ]
  -r, --root              The project root directory

make: *** [relup] Error 127

same v1to2.sh as in my last communication.

[tsloughter]

@blt ok, I just pushed a fix to keep that relfile for the configured release (the one defined in relx.config) if it exists. This fixes the issue with the undefined.rel.

I don't really like the solution though. We may have to fix it up before it goes into erlware/master. I feel it needs to probably do a lot less than it currently is if it is on a relup or tar action.

But let me know if it works so I know I'm on the right track :)

[tsloughter]

@blt oh and note you have to do $ relx release relup, so your makefile or v1to2.sh must change to either run that or after checking out v2 run relx to build the release before relx relup

[blt]

Ah, cool. Thank you. I'd neglected to change that. I altered the Makefile and included v1to2.sh in the repository at commit 619783cd81d77051223d44f65fd96f6c9220b4d1. I'm on your relx fork's 7fad74e:

... 99 skip a few ...
Starting relx build process ...
Resolving OTP Applications from directories:
    /Users/blt/projects/us/troutwine/beat/apps
    /Users/blt/projects/us/troutwine/beat/deps
    /Users/blt/.kerl/installs/R15B03/lib

Resolving available releases from directories:
    /Users/blt/projects/us/troutwine/beat/apps
    /Users/blt/projects/us/troutwine/beat/deps
    /Users/blt/.kerl/installs/R15B03/lib

No releases exist in the system for beat:0.1.0!
Usage: relx [-n <relname>] [-v <relvsn>] [-g <goal>] [-u <upfrom>]
            [-o <output_dir>] [-l <lib_dir>]
            [--disable-default-libs [<disable_default_libs>]]
            [-V [<log_level>]] [-a <override_app>] [-c [<config>]]
            [-r <root_dir>] [*release-specification-file*]

  -n, --relname           Specify the name for the release that will be 
                          generated
  -v, --relvsn            Specify the version for the release
  -g, --goal              Specify a target constraint on the system. These 
                          are usually the OTP
  -u, --upfrom            Only valid with relup target, specify the 
                          release to upgrade from
  -o, --output-dir        The output directory for the release. This is 
                          `./` by default.
  -l, --lib-dir           Additional dirs that should be searched for OTP 
                          Apps
  --disable-default-libs  Disable the default system added lib dirs (means 
                          you must add them all manually [default: false]
  -V, --verbose           Verbosity level, maybe between 0 and 2 [default: 
                          1]
  -a, --override_app      Provide an app name and a directory to override 
                          in the form <appname>:<app directory>
  -c, --config            The path to a config file [default: ]
  -r, --root              The project root directory

make: *** [release] Error 127

If you'd like to confirm yourself, please be aware that the v1 and v2 branches of beat have been force pushed recently.

[tsloughter]

Argh, because ec_dictionary throws an exception instead of returning undefined. Makes sense since you may want undefined to be the element. My bad. Fixing.

[tsloughter]

OK, pushed that fix. You'll need to change your v1to2.sh script a bit. First, renaming your use of _rel/releases/beat-0.1.x to _rel/releases/0.1.x and then to use relx tar after relx relup instead of manually tarring. This may also get rid of the need for all the copy stuff.

Also, if you add -V2 when running relx it adds useful debug output.

[blt]

@tsloughter The extended script that relx produces is still referring to releases/APP-VSN.

> ./_rel/bin/beat-0.1.0 start
egrep: /Users/blt/projects/us/troutwine/beat/_rel/releases/beat-0.1.0/vm.args: No such file or directory

[tsloughter]

Damn, thought I committed that. I've pushed the fix for sure this time :)

[ericbmerritt]

@blt thanks for helping us debug and get this fixed btw.

[blt]

My pleasure, @ericbmerritt.

Okay, this is super close. I've updated beat to commit 72b1a30259708de49bffb20e6aec6c04d5354c73 and see the following after running the new v1to2.sh:

> /tmp/beat/bin/beat-0.1.0 attach
Attaching to /tmp//tmp/beat/releases/0.1.0/erlang.pipe.1 (^D to exit)

([email protected])1> release_handler:unpack_release("0.1.1/beat").      
{ok,"0.1.1"}
([email protected])2> release_handler:install_release("0.1.1").
{error,{enoent,"/tmp/beat/releases/0.1.0/relup"}}

Also, would it be possible for the tarball which is created to be called APP-VSN.tar.gz? I can see this getting confusing in a CI environment if all the release tarballs are APP.tar.gz.

[tsloughter]

Have you updated the repo? The v1to2.sh script I see still in the repo doesn't use use relx tar but still manual tar.

I agree with the tarball name, I don't think systools is going to work to create it with the version in the name, but maybe we can just have relx rename it after creation.

[blt]

Have you updated the repo?

Yes, though I could be doing something wrong. The use of tar in v1to2.sh is to get the base release in a distributable state. That's here: https://github.com/blt/beat/blob/master/v1to2.sh#L20

Then in the Makefile here https://github.com/blt/beat/blob/master/Makefile#L30 I'm calling

relx release relup tar

I agree with the tarball name, I don't think systools is going to work to create it with the version in the name, but maybe we can just have relx rename it after creation.

That would be really nice.

[tsloughter]

Ah ok. And I fixed it and ran through all the steps this time to be sure :)

We were naming it beat.relup instead of just relup and release_handler didn't like that.

Now I'll look at naming the tarball beat-.tar.gz

[tsloughter]

OK, I added the rename, crazy that systools doesn't support giving a name, but whatever. Here is the v1to2.sh I'm running now:

#!/bin/sh

set -e

rm -rf /tmp/beat
rm -rf _rel

git checkout v1
make release
tar cvzf beat-0.1.0.tar.gz -C _rel .

git checkout v2
make relup

mkdir -p /tmp/beat
cp beat-0.1.0.tar.gz /tmp
cp _rel/beat-0.1.1.tar.gz /tmp

cd /tmp/beat
tar xf /tmp/beat-0.1.0.tar.gz
./bin/beat-0.1.0 start

mkdir -p releases/0.1.1
cp /tmp/beat-0.1.1.tar.gz releases/0.1.1/beat.tar.gz

rm /tmp/beat-0.1.0.tar.gz
rm /tmp/beat-0.1.1.tar.gz

Followed by:

$ cd /tmp/beat
$ bin/beat console
Eshell V5.10.2  (abort with ^G)
([email protected])1>  release_handler:unpack_release("0.1.1/beat").
{ok,"0.1.1"}
([email protected])2> release_handler:install_release("0.1.1").
{ok,"0.1.0",[]}

[blt]

I've successfully performed an upgrade! :D

I wasn't able to downgrade, though:

> ./bin/beat-0.1.0 attach
Attaching to /tmp//tmp/beat/releases/0.1.0/erlang.pipe.1 (^D to exit)


([email protected])1> release_handler:unpack_release("0.1.1/beat").
{ok,"0.1.1"}
([email protected])2> release_handler:install_release("0.1.1").    
{ok,"0.1.0",[]}
([email protected])3> release_handler:install_release("0.1.0").
{error,{no_such_file,"/tmp/beat/releases/0.1.0/start.boot"}}

[tsloughter]

Because you packaged beat 0.1.0 manually with tar it didn't do the renaming of beat.boot to start.boot that systools make_tar does. That's why it won't work to downgrade like that.

[blt]

Oh okay, gotcha. I've updated the Makefile in 2343d2e6167cd56c2c0925011bfe3a715cb9db80 to always run 'tar'. I get the following result after running v1to2.sh:

... 99 skip a few ...
Resolved beat-0.1.0
File not found: "/Users/blt/projects/us/troutwine/beat/_rel/releases/0.1.0/beat.rel"
Tarball generation error of beat 0.1.0
Usage: relx [-n <relname>] [-v <relvsn>] [-g <goal>] [-u <upfrom>]
            [-o <output_dir>] [-l <lib_dir>]
            [--disable-default-libs [<disable_default_libs>]]
            [-V [<log_level>]] [-a <override_app>] [-c [<config>]]
            [-r <root_dir>] [*release-specification-file*]

  -n, --relname           Specify the name for the release that will be 
                          generated
  -v, --relvsn            Specify the version for the release
  -g, --goal              Specify a target constraint on the system. These 
                          are usually the OTP
  -u, --upfrom            Only valid with relup target, specify the 
                          release to upgrade from
  -o, --output-dir        The output directory for the release. This is 
                          `./` by default.
  -l, --lib-dir           Additional dirs that should be searched for OTP 
                          Apps
  --disable-default-libs  Disable the default system added lib dirs (means 
                          you must add them all manually [default: false]
  -V, --verbose           Verbosity level, maybe between 0 and 2 [default: 
                          1]
  -a, --override_app      Provide an app name and a directory to override 
                          in the form <appname>:<app directory>
  -c, --config            The path to a config file [default: ]
  -r, --root              The project root directory

make: *** [release] Error 127

[blt]

Okay, I had to explicitly change that to relx release tar in the Makefile. You'll find that in 208efc758ddea029093bbb58a63e0094fd5a26da. Thereafter:

> /tmp/beat/bin/beat-0.1.0 attach
Attaching to /tmp//tmp/beat/releases/0.1.0/erlang.pipe.1 (^D to exit)


([email protected])1> release_handler:unpack_release("0.1.1/beat").
{ok,"0.1.1"}
([email protected])2> release_handler:in
init/1             install_file/2     install_release/1  install_release/2  

([email protected])2> release_handler:install_release("0.1.1").
{ok,"0.1.0",[]}
([email protected])3> release_handler:install_release("0.1.0").
{error,{no_such_file,"/tmp/beat/releases/0.1.0/start.boot"}}

Still can't downgrade. Also, the extended script that relx produces has an 'upgrade' option. It references an install_upgrade.escript but relx does not include this file in release builds.

Still, hey, I can totally do an OTP upgrade now with relx!

[tsloughter]

And /tmp/beat/releases/0.1.0/start.boot exists?

After we get that part figured out lets open another issue fir install_upgrade.escript

[tsloughter]

Ignore my second part. I added install_upgrade.escript to my branch and the PR. It fits under this issue after all. Let me know if it works for you as expected.

[blt]

When attempting the upgrade with the extended script:

> /tmp/beat/bin/beat-0.1.0 upgrade "0.1.1/beat"
escript: Failed to open file: /tmp/beat/bin/bin/install_upgrade.escript

when attempting to upgrade and downgrade:

> /tmp/beat/bin/beat-0.1.0 attach              
Attaching to /tmp//tmp/beat/releases/0.1.0/erlang.pipe.1 (^D to exit)


([email protected])1> release_handler:unpack_release("0.1.1/beat").
{ok,"0.1.1"}
([email protected])2> release_handler:install_release("0.1.1").    
{ok,"0.1.0",[]}
([email protected])3> release_handler:install_release("0.1.0").
{error,{no_such_file,"/tmp/beat/releases/0.1.0/start.boot"}}

Here's the releases/ tree:

> tree /tmp/beat/releases 
/tmp/beat/releases
├── 0.1.0
│   ├── beat.boot
│   ├── beat.rel
│   ├── beat.script
│   ├── log
│   │   ├── erlang.log.1
│   │   └── run_erl.log
│   ├── sys.config
│   └── vm.args
├── 0.1.1
│   ├── relup
│   ├── start.boot
│   └── sys.config
├── RELEASES
└── beat.rel

3 directories, 12 files

[tsloughter]

@blt right, you are not going to be able to do an install_release on 0.1.0 as long as you are tarring it manually and not changing the names to start.boot. Nothing to change in relx for that.

As for running the upgrade I once again pushed without testing :). I fixed the path and tested that it runs (though haven't tried running an upgrade with it just that the script ran and errored from invalid ugprade name). I forced pushed that patch to my repo.

[blt]

@blt right, you are not going to be able to do an install_release on 0.1.0 as long as you are tarring it manually and not changing the names to start.boot. Nothing to change in relx for that.

I'm not tarring it up manually any more. 0.1.0 is built with the 'make release' from https://github.com/blt/beat/blob/master/Makefile#L27 which translates to:

relx release tar

The pertinent line in v1to2.sh: https://github.com/blt/beat/blob/master/v1to2.sh#L9

As for running the upgrade I once again pushed without testing :). I fixed the path and tested that it runs (though haven't tried running an upgrade with it just that the script ran and errored from invalid ugprade name). I forced pushed that patch to my repo.

After updating from your repo and updating relx, I see:

> /tmp/beat/bin/beat-0.1.0 upgrade "0.1.1/beat"
escript: Failed to open file: /tmp/beat/bin/bin/install_upgrade.escript

Partially the line in beat-0.1.0 script is

$SCRIPT_DIR/bin/install_upgrade.escript 

and

SCRIPT_DIR=`dirname $0` 

is the definition, so I think that should be $SCRIPT_DIR/install_upgrade.escript. Once I change that--and I think it should be changed through the file--I find:

> /tmp/beat/bin/beat-0.1.0 upgrade "0.1.1/beat"

=INFO REPORT==== 10-Sep-2013::17:49:11 ===
Can't set short node name!
Please check your configuration
escript: exception error: no match of right hand side value 
                 {error,
                     {shutdown,
                         {child,undefined,net_sup_dynamic,
                             {erl_distribution,start_link,
                                 [['[email protected]_upgrader_55053',
                                   shortnames]]},
                             permanent,1000,supervisor,
                             [erl_distribution]}}}

[tsloughter]

I did make that change, but I force pushed the change since I rebased. maybe that's why you didn't get it?

and damn, ok, I'll look at doing the full thing including downgrade in a minute.

[blt]

I did make that change, but I force pushed the change since I rebased. maybe that's why you didn't get it?

Hmm, I'm reasonably certain I'm at your repository's latest commit: 416d107

[tsloughter]

Yea, the change is there at line 846.

Going to try running this now and see how far I get.

[tsloughter]

I have a few problems with the script.

./v1to2.sh: 19: ./v1to2.sh: ./bin/beat-0.1.0: not found

I guess because systools:make_tar doesn't include the bin directory. Nor is erts copied. Let me play around with systools to get those included in a tar.

[tsloughter]

Ok... SO. We need to have both the option to use http://www.erlang.org/doc/system_principles/create_target.html or systools:make_tar. make_tar can't include all the things necessary for a target_system. We used to just tar everything ourselves with sinan and basically make our own target system, but that doesn't do the renaming, thus breaks using release_handler.

So I suppose there will be $ relx tar and $ relx target_system

[tsloughter]

Spoke too soon. I was able to get beat-0.1.0 to boot after adding erts to the make_tar. There are 2 issues that show up from this though.

1. make_tar won't include vm.args -- no idea a way around that yet besides after making the tar.gz having relx unpack, fix it up and repackage
2. using make_tar means the start script has to use start.boot instead of the current <relname>.boot

Clearly this whole tool chain was not made to be easy to use, haha.

But I want to make this easy to do. If I have to do (1) that is fine, sucks, but works. For (2) I'm not sure yet. Best I can think of is setting BOOTFILE to which ever of those 2 exists, since it is based on a path of releases/<relvsn> anyway it isn't going to hurt anything.

I can take care of those tomorrow. Hopefully I'm right about those 2... :)

@ericbmerritt this shit is hairy, but I think we are close to have a tool that makes this shit unhairy!

[blt]

Yea, the change is there at line 846.

You're right, I see it right here: https://github.com/erlware/relx/pull/29/files#L2R850 This was a problem on my end, fixed in commit 7227ffdf3da9ab2c0ad5b2ce6df14abbb29b0093.

Clearly this whole tool chain was not made to be easy to use, haha.

+1 :D

I have a few problems with the script.

That's... unexpected. Turns out it was an issue on my end. You're seeing that because the 0.1.0 tarball does not include the bin/ directory in the release. I suppose that means anything defined in an overlay will not be in a release tarball, either. Hmm...

Anyway, the culprit is the reliance on relx release tar to provide a base system where, previously, I just used relx and whatever defaults that brings in.

You should be able to use v1to2.sh to confirm changes with beat. Let me know if you're still having problems.

[blt]

As of 336f8f7fddea2fbc4115c3ac1f8cb183b85bde8e v1to2.sh will attempt to make an automatic upgrade to 0.1.1 via install_upgrade.escript.

[tsloughter]

Wooo! It works, but get rid of your bin/install_upgrade.escript and your overlay for copying it.

$ sh v1to2.sh
$ cd /tmp/beat
$  bin/beat-0.1.0 upgrade "0.1.1/beat"
Unpacked Release "0.1.1"
Installed Release "0.1.1"
Made Release "0.1.1" Permanent

[tsloughter]

You may still get an error enoent when running the upgrade. The beat 0.1.0 daemon doesn't have a cwd set and that is what cause it to crash. Still working on figuring that out.

[tsloughter]

Fixed, shouldn't be an issue now.

[blt]

Oh yeah, heh, forgot about the overlay. :)

Cool, I'll pull the latest relx and give it a go.

[tsloughter]

Though, actually now it is always telling me it is already installed, hehe. So may still have an issue somewhere.

[tsloughter]

Oh, I think it is because v1to2.sh doesn't stop beat if it is already running. So when you run upgrade again the old beat is still running and already has 0.1.1 set as an available release :). So for testing/example may want to add a stop call in v1to2.sh

[blt]

Heh, you're outpacing me. :) I noticed that and am doing that now.

[blt]

Minor comment, lines like "tarball /Users/blt/projects/us/troutwine/beat/_rel/beat-0.1.1.tar.gz successfully created!" don't end in a newline.

I've upgraded beat to 0c25d4f7aae25a3111b8971a7d029b845088ce5a and now when I run v1to2.sh find I can upgrade to 0.1.1 no problem! :D Have done it a few times just to be sure.

[blt]

Still having trouble downgrading:

([email protected])1> release_handler:which_releases().
[{"beat","0.1.1",
  ["kernel-2.15.3","stdlib-1.18.3","beat_core-2013.2",
   "ranch-0.8.5","beat_tcp_api-2013.1","sasl-2.2.1"],
  permanent},
 {"beat","0.1.0",[],old}]
([email protected])2> release_handler:install_release("0.1.0").
{error,{'EXIT',{{case_clause,false},
                [{release_handler_1,eval,2,
                                    [{file,"release_handler_1.erl"},{line,309}]},
                 {lists,foldl,3,[{file,"lists.erl"},{line,1197}]},
                 {release_handler_1,eval_script,5,
                                    [{file,"release_handler_1.erl"},{line,90}]},
                 {release_handler,eval_script,5,
                                  [{file,"release_handler.erl"},{line,366}]},
                 {release_handler,do_install_release,3,
                                  [{file,"release_handler.erl"},{line,1028}]},
                 {release_handler,handle_call,3,
                                  [{file,"release_handler.erl"},{line,617}]},
                 {gen_server,handle_msg,5,
                             [{file,"gen_server.erl"},{line,588}]},
                 {proc_lib,init_p_do_apply,3,
                           [{file,"proc_lib.erl"},{line,227}]}]}}}

[blt]

Oh, also, this is fun:

> /tmp/beat/bin/beat-0.1.1 attach
Can't access pipe directory /tmp//tmp/beat/releases/0.1.1/: No such file or directory

The script hard-codes the VSN information to know which pipe to look up. Means you have to keep track, in production, of which VSN you initially deployed so you can connected to the running node.

[tsloughter]

I'm not sure what, if anything, to do about downgrading to the initial release. The issue is that it's libs list is empty. Likely because it wasn't "installed" the same way. I can't find anything with a quick google search about how to get around that issue. But happy to fix it if one of us do and it is something relx can help with.

As for the attach issue, not sure what we can do there either. Maybe just remove the version number from the path for the pipes?

[blt]

I'm not sure what, if anything, to do about downgrading to the initial release. The issue is that it's libs list is empty. Likely because it wasn't "installed" the same way. I can't find anything with a quick google search about how to get around that issue. But happy to fix it if one of us do and it is something relx can help with.

I find this to be an acceptable limitation, so long as it gets documented. ;)

As for the attach issue, not sure what we can do there either. Maybe just remove the version number from the path for the pipes?

That makes the most sense to me.

[tsloughter]

Cool, I pushed a change to use a dir without version number for the pipes dir.

And will be sure to include that issue with the first release in the documentation I plan to write this weekend.

Are we ready to close this issue now? Almost to 60 comments! hehe

[blt]

Excellent! Been a long time coming. :)

Thank you so much for your persistence. This has been wonderful.

[tsloughter]

And thanks for yours! I learned a lot and hopefully we put relx in a great position to take over release handling for Erlang projects.

[tsloughter]

Issue resolved in PR #29