On Thu, Apr 23, 2015 at 08:58:28AM -0400, Fabian Deutsch wrote:
> Hey,
> 
> the logic which is run on vdsm upgrades is located in the specfile, and thus 
> run
> when the rpm get's an update.
> This is fine as long as rpm is involved (like when rpm or yum or dnf is 
> used), but it
> becomes - and already is - an issue for flows where the upgrade happens 
> without
> rpm, like on oVirt Node.
> 
> On oVirt Node the image for booting the host is getting replaced, we 
> currently mimic
> the upgrade process of the specfile. But this error prone - we had a lot of 
> bugs around
> this area (remember the problems with the hooks?), and we need to watch out 
> for changes
> in the upgrade logic.
> 
> To simplify and especially unify the logic between Node and normal hosts, I'd 
> like to
> discuss if the upgrade logic can be moved to a separate service or included 
> in one of the
> existsing services.
> 
> The simplest approach to me would be top create a new service which is 
> started before
> libvirtd and vdsmd/supervdsmd to run some logic if an upgrade of vdsm is 
> detected.
> This habit - to do the upgrade logic during boot - is actually not new and 
> systemd
> provides some helpers (ConditionNeedsUpdate=) around this to ease the 
> implementation.
> 
> Thoughts?

The problem is real: we have too much logic on %post and %postun
scripts, and end up with upgrade bugs litterally on every release.

However, for non-node installation we still need to allow configuration
after upgrade, but before next boot. This means that everything in %post
should be converted into vdsm-tool "configurators".
https://gerrit.ovirt.org/#/c/39823/3/vdsm.spec.in is one small step in
that direction.

When Vdsm starts up, it performs several "upgrade" modules, which
are used to upgrade vdsm-specific configurations. These too should
operate properly also when run much after boot.

Hence, I'm not sure about the benefit of adding an early systemd
service, but I may be missing something.

_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Reply via email to