| Age | Commit message (Collapse) | Author |
|---|
|
* siri/sasl/upgrade-erts/OTP-9438:
Fix bug in erts upgrade on windows
Add release vsn info to erts_vsn_changed warning
Check for sasl application in systools:make_script and make_relup
Add syntax check of relup to check_install_release and install_release
Add documentation for upgrade from pre R15 to post R15 sasl
Handle upgrade from pre R15 to post R15 sasl
Step version of sasl to 2.2 for R15
Document upgrade instructions restart_new_emulator and restart_emulator
Wait for two restarts in upgrade_restart test
Add restart_new_emulator instruction to kernel, stdlib and sasl appups
Distinguish restart_new_emulator from restart_emulator in upgrade instructions
Upgrade erts: merge sys.config for tmp release instead of using old
Allow regexp for version in .appup
Restart emulator before running upgrade script when erts is upgraded
Conflicts:
lib/sasl/src/release_handler.erl
lib/sasl/test/release_handler_SUITE.erl
|
|
|
|
make_script will give warning but allow it
make_relup will fail since it is not possible to upgrade if sasl is
not included in both releases.
|
|
New emulator upgrade mechanism introduced in R15 can only work if the
sasl version to upgrade from is 2.2 or later. I.e. if we are already
running at least R15.
This commit adds backwards compatiblity for upgrades from earlier
versions, meaning that the new code is loaded into the old emulator
and code_change is executed - then after all application code is
updated, the emulator is restarted with the new erts version.
Note that this might cause problems if the new code is compiled with
the new emulator and there have been updates to the beam format. If
this happens, the workaround is to compile the new code with the old
emulator.
|
|
The appup files for kernel, stdlib and sasl did not contain any
UpFromVsn and DownToVsn. This means that it was not possible to create
a relup file with systool:make_relup if any of these applications had
changed.
This commit adds entries in the appup files for a maximum of two major
releases back - all with only one upgrade instruction:
restart_new_emulator. The point is to allow relups to be generated,
but ensure that no soft upgrade is done for these three applications -
i.e. they will always cause a restart of the emulator prior to all
other upgrade instructions from other applications.
Test cases (appup_test) are added to kernel_SUITE, stdlib_SUITE and
sasl_SUITE. These all check that expected versions are matched in the
appups, and illegal versions (older than two major releases, or in any
other way illegal) do not match. The test is written in a general way
where it is assumed that the version of these applications are stepped
according the the rule that major releases step the second number,
maintenance releases step the third number and patches step the fourth
number.
|
|
Earlier, there was only one valid instruction to restart the emulator
in an appup/relup script, 'restart_new_emulator'. A new instuction,
'restart_emulator', is now added, and the meaning is as follows:
'restart_new_emulator' is mainly for the core applications (erts,
kernel, stdlib and sasl), and it indicates that there is new core
functionality in the release and the emulator needs to be restarted
before executing the upgrade scripts. If this instruction exists, a
temporary release will be created which consists of the new version
erts, kernel, stdlib and sasl, and the old versions of all other
applications. After restarting the emulator with this temporary
release, the rest of the upgrade instructions are executed, including
loading of new versions.
'restart_emulator' can be used by any application if a restart of the
emulator is needed after the upgrade instructions have been
executed. In this case, the emulator will be restarted with the new
release (i.e. not a tempoarary one) after all other upgrade
instructions for all applications have been excecuted.
|
|
In order to avoid duplication of upgrade instructions in .appup files,
we now allow regular expressions to specify the UpFrom and DownTo
versions. To be considered a regular expression, the version
identifier must be specified as a binary, e.g.
<<"2\\.1\\.[0-9]+">> will match versions 2.1.x, where x is any number.
|
|
If the version of erts differs between two releases, the release
handler automatically adds a 'restart_new_emulator' instruction to the
upgrade script (relup). Earlier, this instruction was always added at
the end of the upgrade script, causing the following sequence of
operations during an upgrade (a bit simplified):
1. suspend processes
2. load new code
3. execute code_change functions
4. resume processes
5. restart emulator with new erts version
Obviously, this caused the new code to be loaded into the old emulator
and this would fail if the beam format had been changed in the new
version of the emulator.
To overcome this problem, this commit changes the order of the
instructions, so for upgrade with changed erts version we now have:
1. restart emulator with new erts, kernel, stdlib and sasl versions,
but old versions of all other applications.
2. suspend processes
3. load new code
4. execute code_change functions
5. resume processes
This is implemented by creating a temporary release, including new
erts, kernel, stdlib and sasl from the new release and all other
applications from the old release. A new boot file for this temporary
release is created, which includes a new 'apply' instruction to run
release_handler:new_emulator_upgrade/2. Then the emulator is restarted
using this boot file - and release_handler:new_emulator_upgrade/2
executes the rest of the upgrade script.
For downgrade, the order will be as before:
1. suspend processes
2. execute code_change functions with 'down'-indication
3. load old code
4. resume processes
5. restart emulator with old erts version
|
|
|
|
Add new option <c>src_tests</c> to systools:make_script and
systools:make_tar. The old option <c>no_module_tests</c> is now
ignored as this is the default behaviour.
|
|
|
|
Previously, relup file always included an
application:start(Application, permanent) apply instruction for every
application that appear in the UpTo/DowFrom release file, whatever
their start type in the release file.
The new implementation fixes this bug by honoring the start type
according to the rel(5) format. If the start type is none, no apply
line is included in the relup. If the start type is load, the relup
includes instruction to only load the application. Otherwise, the
relup includes an instruction to start the application to the
according type.
The fix is implemented by adding a new parameter to the
add_application high level appup instruction. This new parameter is
documented in appup(5).
|
|
|
