Univention Bugzilla – Bug 39204
Upgrade of Docker container
Last modified: 2015-11-17 12:12:23 CET
By default the App Docker container are not read-only container. Thus, changes are written into a separate layer. This write-able layer is not destroyed while rebooting the container. Updates can be delivered in two different ways: 1. Inside the container 2. Outside the container Inside the container: By default all errata and patchlevel updates of the container operating system, normally a UCS, are installed automatically inside the container. This means, the updates are written into the write-able container. Also App updates can be installed in this way. By default these App updates are not installed automatically. Outside the container: The other way is to provide updates as a new container or simply as a new container layer. This is normally used for major operating system upgrade or for major App updates. Although, it is also possible to use it for errata updates. The image layer update does not deliver only one new layer which would be added above the existing layer. This is not possible due to the write able layer. In contrast a new container is generate. Certainly, it can base on the same layer as the previous container. The data migration is executed by a script provided by the new App version. The script is executed on the host system and has permissions to the new container, to new old container and to a temporary directory. Thus, the image can copy and migrate data between the existing container. It is also allowed to start and to stop the existing container. Usually, the new container does not need to re-join, if the container needs to re-join, it asks for the credentials. The data migration script has the possible to stop the upgrade. In this case the script can give an error message to the App Center. All available updates (inside and outside the container) are shown in the App Center and can be pushed manually. It should be visible if the upgrade is installed automatically.
(In reply to Stefan Gohmann from comment #0) > Usually, the new container does not need to re-join The default store data scripts should copy the join status. I've created Bug #39462 for it.
(In reply to Stefan Gohmann from comment #1) > (In reply to Stefan Gohmann from comment #0) > > Usually, the new container does not need to re-join > > The default store data scripts should copy the join status. I've created Bug > #39462 for it. The default setup script in univention-docker-container-mode does now recognize if the system has already been joined. In this case the setup script only runs univention-run-join-scripts.
(In reply to Stefan Gohmann from comment #0) > Inside the container: By default all errata and patchlevel updates of the > container operating system, normally a UCS, are installed automatically > inside the container. This means, the updates are written into the > write-able container. Also App updates can be installed in this way. By > default these App updates are not installed automatically. The App Center creates two policies and connects them to each and every (read: this is not configurable) new docker container. These policies install all updates, errata and release updates automatically. The cron job runs at 1 am. No policy for app updates available. To prevent this functionality, an admin can change the policies for that host.
The data migration script is a little bit different from the original description but I think it is OK for now.
See also Bug #39618.
Updates inside (UCS) FAIL - policy -> more /etc/cron.d/univention-maintenance * 1 * * * ... I think this means every minuter between 1pm and 2pm? FAIL - Updates (everything at the moment, but will be improved with Bug #9618) started /usr/share/univention-updater/univention-updater net --noninteractive inside the container (this is what the cron job does) in the updater.log, i see 04.11.15 11:37:30.271 DEBUG_INIT **** Starting univention-updater with parameter=['/usr/share/univention-updater/univention-updater', 'net', '--noninteractive'] Version=4.1 Patchlevel=0 starting net mode --->DBG:update_available(mode=net, cdrom_mount_point=/media/cdrom0, iso=None) Checking network repository System is up to date (UCS 4.1-0) Starting univention-upgrade. Current UCS version is 4.1-0 errata0 Checking for local repository: skipped Checking for release updates: none Checking for package updates: none Checking for app updates: Calling with Namespace(app=None, help='==SUPPRESS==') Why?
(In reply to Felix Botner from comment #6) > Updates inside (UCS) > > FAIL - policy > > -> more /etc/cron.d/univention-maintenance > * 1 * * * ... > I think this means every minuter between 1pm and 2pm? Changed to "5 1 * * *": r65163 > FAIL - Updates (everything at the moment, but will be improved with Bug > #9618) > > started /usr/share/univention-updater/univention-updater net --noninteractive > inside the container (this is what the cron job does) > in the updater.log, i see > > 04.11.15 11:37:30.271 DEBUG_INIT > **** Starting univention-updater with > parameter=['/usr/share/univention-updater/univention-updater', 'net', > '--noninteractive'] > Version=4.1 > Patchlevel=0 > starting net mode > --->DBG:update_available(mode=net, cdrom_mount_point=/media/cdrom0, iso=None) > Checking network repository > System is up to date (UCS 4.1-0) > > Starting univention-upgrade. Current UCS version is 4.1-0 errata0 > > Checking for local repository: skipped > Checking for release updates: none > Checking for package updates: none > Checking for app updates: Calling with > Namespace(app=None, help='==SUPPRESS==') > > Why? It is just a simple /usr/share/univention-updater/univention-updater-check for checking if an update is available. That's OK.
OK - Updates inside (UCS) * policy * updates (everything at the moment, but will be improved with Bug #9618) FAIL - docker app and image update * i updated a docker app (new docker image and new app version) appcenter.log Calling docker exec store_data - OK Stopping dudle-docker Container b2cc3be - OK Preconfiguring container 31618cd5fc6df6 - OK Calling docker exec 316 restore_data_before_setup - OK Calling docker exec 31618 setup - !!!!!!!!!!!! setup is basically univention-join, so after restore_data_before_setup the container joins again? is that correct
Created attachment 7256 [details] appcenter.log
(In reply to Felix Botner from comment #8) > FAIL - docker app and image update > * i updated a docker app (new docker image and new app version) > appcenter.log > Calling docker exec store_data - OK > Stopping dudle-docker Container b2cc3be - OK > Preconfiguring container 31618cd5fc6df6 - OK > Calling docker exec 316 restore_data_before_setup - OK > Calling docker exec 31618 setup - !!!!!!!!!!!! > > setup is basically univention-join, so after restore_data_before_setup the > container joins again? is that correct The re-join is not OK. We implemented a join status copy: Bug #39462. The logfile shows that you used a 4.0-3 docker image. If you use a default 4.0-3 image, the store_data, restore_data_before_setup scripts are too old and buggy. You can overwrite them, see 80_docker/64_app_container_upgrade, for example: app.add_script(store_data=store_data_script_4_1()). If you used the new store_data, restore_data functions, please re-open.
OK - updates inside (policy, cron-job) OK - NO updates if new docker image but no app update OK - app update OK - Changelog
UCS 4.1 has been released: https://docs.software-univention.de/release-notes-4.1-0-en.html https://docs.software-univention.de/release-notes-4.1-0-de.html If this error occurs again, please use "Clone This Bug".