#6968 Consider moving upgrades from rpm install post
Closed: fixed 6 years ago Opened 6 years ago by simo.

During system upgrades, Fedora systems avoid bringing up the network, and in general we've seen in other cases that there may be issues running upgrade scripts while bits are being laid down on the disk.

We should think if the upgrade scripts should instead be run at ipa service startup. This could be reasonably easily be done with a pre-exec script in the ipa service unit, or by having an ipa-upgrade service unit as a dependency and blocking service for other ipa services.

Besides avoiding issue during system upgrades, the advantage is that we can recover from an ipa upgrade transient issue simply by restartgin the ipa service, and, on fatal errors stop the ipa service from starting entirely.

Inspired by: https://bugzilla.redhat.com/show_bug.cgi?id=1452866


Fedora 26 needs to be fixed. More complex version can land in 4.5.x

Metadata Update from @pvoborni:
- Issue priority set to: blocker
- Issue set to the milestone: FreeIPA 4.4.5

6 years ago

Metadata Update from @pvoborni:
- Issue priority set to: important (was: critical)
- Issue set to the milestone: FreeIPA 4.8 (was: FreeIPA 4.4.5)

6 years ago

This is now effectively blocking the Fedora 27 Server release, via https://bugzilla.redhat.com/show_bug.cgi?id=1503321 .

This wasn't really blocking for Fedora 26, because on upgrade from 24 or 25 to 26, even though the IPA upgrade script failed to run fully, FreeIPA still mostly worked. But for upgrade to F27, that is no longer the case: FreeIPA flat fails to start on the upgraded system, and that bug is accepted as a blocker for the Fedora 27 Server Beta release, which we are trying to do at the moment. So we really need this fixed.

BTW, what about the paradigm commonly found in webapps? These often store some sort of schema version somewhere, and on every startup, the app checks if an upgrade is necessary (based on the schema version) and runs the upgrade process automatically if it is...

I think the upgrade script could be run at every startup without too much of an impact, we should probably go that route for now until this problem can be handled better.
slowing down startup is not a huge deal for now.

It shouldn't be too much work to just stick some kinda 'version' indicator in somewhere which the upgrade script could check for and immediately exit if it was up to date, should it?

Metadata Update from @rcritten:
- Issue assigned to rcritten

6 years ago

In the past we used the upgrade script to 'repair' an installation, e.g. re-create custodia config and keys. AFAIK FreeIPA's ipapython/version.py only tracks upstream releases and not internal package upgrades. There might be no easy way to get the actual version easily.

May I suggest a slightly different approach?

1) rpm post-install creates /var/lib/ipa/needs-upgrade
2) ipa-server-upgrade --check-upgrade only runs upgrade when upgrade file is present. Just ipa-server-upgrade still runs upgrade unconditionally.
3) On successful ipa-server-install and ipa-server-upgrade, the file is removed
4) ipa-server-upgrade --check is executed by ipa start or as ExecStartPre hook in ipa.service

That seems fairly reasonable, sure. I tend to like distro-neutral upstream implementations where possible, but that looks like it would work fine. I'd just suggest explicitly logging messages around this that reference the actual filename of the 'check' file, so that if someone somehow gets stuck in some kind of loop, they know what's going on.

Metadata Update from @pvoborni:
- Issue priority set to: critical (was: important)
- Issue set to the milestone: FreeIPA 4.6 (was: FreeIPA 4.8)

6 years ago

Metadata Update from @pvoborni:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1452866

6 years ago

Metadata Update from @pvoborni:
- Issue set to the milestone: FreeIPA 4.6.2 (was: FreeIPA 4.6)

6 years ago

master:

  • d7aa794 Run server upgrade in ipactl start/restart

ipa-4-6:

  • b2d3b56 Run server upgrade in ipactl start/restart

Metadata Update from @tdudlak:
- Issue set to the milestone: FreeIPA 4.6.3 (was: FreeIPA 4.6.2)

6 years ago

Metadata Update from @rcritten:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata