| Age | Commit message (Collapse) | Author |
|---|
|
* siri/sasl/correct-app-name-in-error/OTP-9888:
Fix error message if stdlib has faulty start type in .rel file
|
|
* siri/sasl/doc-regexp-in-appup/OTP-10001:
Add documentation of regular expressions for version numbers in appup
|
|
If stdlib had a different start type than permanent, systools_make
would fail but it would say that it was sasl that had faulty start
type. This has been corrected.
|
|
|
|
OTP-9984
Applications that are listed in {applications,Apps} in the app file
were not sorted correctly in the script file. They were loaded/started
in the reverse order of how they were listed in the .app file.
This is corrected so they are now sorted (internally between each
other) in the same way as they are listed in the .rel file.
|
|
OTP-9980
Sasl documentation earlier said that the InclApps parameters in a .rel
file defaults to the empty list. This is not correct. It defaults to
the same value as specified in the .app file.
|
|
remove_file in release_handler would fail silently and leave directories
in inconsistent states if there was symlinks in a release directory
also added a test, otp_9864 to test change
|
|
|
|
* siri/sasl/check-config-in-tar/OTP-9539:
Check that sys.config and relup have valid content when added to tar
|
|
systools:make_tar now does a minor check of the content of sys.config
and relup before adding them to the tar file. If the content is not
readable or in expected format, the function fails.
|
|
It should not be possible to create a .boot file unless kernel and
stdlib are stated as permanent applications in the .rel file. Note
that 'permanent' is the default start type, so not specifying a start
type for kernel and stdlib is, as always, ok.
|
|
|
|
* siri/sasl/convert-to-common-test/OTP-9740:
Convert sasl test suites to pure common test style
|
|
|
|
|
|
|
|
Fix typos or minor faults.
Move out code listing of target_system.erl, and use codeinclude
statement to include this file from sasl/examples directory.
|
|
* siri/stdlib/dialyzer-supervisor/OTP-9741:
Add test for upgrade of supervisor
Fix dialyzer warnings in supervisor
|
|
systools:make_tar has recently been updated to store the .rel file
in both releases and releases/<vsn> directories. Ths same commit
removed copying of this file from releases to releases/<vsn> in
release_handler:unpack_release. This commit adde this copy again to
make sure the file is not lost if the tar file was created with an
older systools.
|
|
The test is added in release_handler_SUITE since this makes it
possible to test the full upgrade instead of just a simple library
test of supervisor:code_change.
|
|
Dialyzer complained over a mismatch between the callback spec of
Mod:code_change in gen_server and the spec of supervisor:code_change
(which is the implementation of a gen_server Mod:code_change).
This commit changes the callback spec to allow {error,Reason} as
return value. Also, release_handler is updated to handle this return
value.
|
|
systool:make_tar stores the rel file in the releases directory. When
unpacking with release_handler:unpack_release, the file is
automatically moved to releases/<vsn>/. If, however, the tar file is
unpacked manually, the rel file might not be moved, and the next
release unpacked might overwrite the rel file. To overcome this,
systools:make_tar now stores a copy of the rel file in releases/<vsn>/
directly and it is not longer necessary to move the file after
unpacking.
The reason for keeping the file in the releases directory also is that
is needs to be extracted separately before the release version <vsn>
is known.
|
|
* siri/sasl/no-warn-missing-sasl/OTP-9738:
Add +no_warn_sasl flag when compiling start_clean.rel
Add option no_warn_sasl to systools:make_script
|
|
* siri/sasl/xxgrade_app-with-restart/OTP-9735:
Fix release_handler:upgrade_app and downgrade_app when upgrading emulator
|
|
This option will suppress the 'missing-sasl' warning which otherwise
is issued when compiling a .rel file which does not include the sasl
application.
|
|
Changes to the mechanism for upgrading the emulator in OTP R15 was
erronously not handled in release_handler:upgrade_app, downgrade_app,
upgrade_script and downgrade_script. This has been corrected,
including test and documentation.
|
|
This reverts commit e21ff9b0b69219ab3853be7e80813156113152b7.
|
|
|
|
|
|
* 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
|
|
* jw/release_handler-which-releases:
Add release_handler:which_releases/1
OTP-9717
|
|
The service which represents the temporary release during erts upgrade
on windows was never deleted. This has been corrected. The service is
now renamed just after the emulator restart.
|
|
|
|
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.
|
|
This commit adds a check that all instructions in the relup are
valid. Earlier, the last part (after point_of_no_return) was not
checked before the actual installation started, meaning that if the
relup was hand written, there was a potential for crashing the upgrade
here.
|
|
|
|
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.
|
|
This is needed for sasl_SUITE:appup_test to work, therefore we do not
wait until release time.
|
|
|
|
This is an attempt to correct a failing test case. It the test fails
on having restarted only once, we give it another try to see if the
second restart will happen.
|
|
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.
|
|
The sys.config file used for the temporary release in an erts upgrade
is now a hybrid where kernel, stdlib and sasl configuration is taken
from the new release, and other configuration is taken from the old
release. I.e. similar to how the temporary boot file is created.
|
|
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
|
|
|
|
These dependency files was once used when building the documentation,
but are no longer needed.
|
|
This is an extension to which_releases that allows a user to specify the
status of the releases they wish to be returned. For instance it allows
for quickly determining which release is 'permanent' without the need of
parsing the entire release list.
|
|
|
|
|
