With FreeIPA in a container (https://github.com/adelton/docker-freeipa), the configuration and data produced by the versions of IPA and its components during initial ipa-server-install are stored in a volume. Files and directories stored on the volume are listed at
https://github.com/adelton/docker-freeipa/blob/master/volume-data-list
and they are symlinked from the image (for example, /var/lib/dirsrv -> /data/var/lib/dirsrv).
It is then possible to use image built with different (newer) version of IPA or even built on different OS (Fedora -> CentOS) and start new container with this new image, giving it volume populated with configuration and data files produced by the old container. At that point, upgrade process needs to be run to make the data and configuration match the versions of the software being started in the container.
In normal installation, upgrades are often achieved at rpm upgrade time, in %post scriptlets. That seems to be the case for 389-ds-base as well so in
https://github.com/adelton/docker-freeipa/blob/master/ipa-server-configure-first#L49
in function upgrade_server we actually get the scriptlet from 389-ds-base and run it verbatim. It seems to do quite a lot of operations and this approach typically works.
It'd be nice for 389 to provide a single generic tool which would handle upgrades completely, for reasonable mix of old / new versions, taking into account that with containers, people are likely to try wilder combinations than when the classical "I have my rpm-based machine, I upgrade with yum" setup is used.
What functionality do you require other than what is already provided by setup-ds.pl -u?
If
{{{ /usr/sbin/setup-ds.pl -u -s General.UpdateMode=offline }}}
is all that is needed, then I guess just packaging it in some script with descriptive name.
The goal is for the 389 project to give others (like FreeIPA) stable interface. So if in newer versions, setup-ds.pl needs new option to do the right thing, that should be hidden inside of 389-server-upgrade script, so that the interface from other projects does not change.
Ok. Are there any new requirements for the functionality of setup-ds.pl -u itself?
I don't have any new requirements. Basically, in the container, new software version is run with old data and if it's detected that it was not the image used the last time, the upgrade will be run.
Per triage, push the target milestone to 1.3.6.
Metadata Update from @nhosoi: - Issue set to the milestone: 1.3.6.0
we are currently pursuing docker integration with #49207 , and part of this is this understanding. Due to our cleanup of cn=config, the need of setup-ds.pl -u is eliminated. For us, this is actually a huge benefit, as this removes lots of hacks in our rpm, our reliance on these perl tools, and makes containers better.
In the future, we should shift to ns-slapd having "update modules", so that this use case works. I think that this is covered in part by #49211 which really captures the issue at hand here.
As well, issues like #48864 , #49213 and #49212,address finegrained docker integration points that have not yet been raised or considered.
As a result, I think that if you want to follow this issue, follow the issue listed because they are more detailed than this, and express our integrations better.
Metadata Update from @firstyear: - Custom field reviewstatus adjusted to new - Issue close_status updated to: duplicate - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1493
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: duplicate)
Login to comment on this ticket.