That is a very polite way of saying “go read the code you lazy prick”, thanks!
And so I did. And I have started losing context somewhere around /usr/lib/python3.11/site-packages/vmupdate/agent/source/dnf/dnf_api.py. I’m not very solid about stuff.
Regardless, as far as I can tell, pgk_mng.upgrade runs upgrade from ./source/common/package_manager.py. There, refresh does nothing. It seems to be not implemented. Same goes to get_action in upgrade_internal.
I’m missing the part where it calls upgrade_internal from dnf_api.py (I suspect that this is what it really does, because upgrade_internal in common/package_manager.py doesn’t seem to be doing anything).
Because of that I don’t know how is it even possible to have a running template with updates available, and yet never apply them until reboot. I guess I should look into dnf.base.upgrade_all() for that.
Still, this UX decision is concerning. If user wants to “update all targeted VMs even if no updates are available”, it means user expects there to be an update, even if the system isn’t aware of it, therefore it must refresh package information to be useful.
Also I believe that this program is missing an important functionality: force update, force package information refresh, but don’t ignore errors.
I want to look more into this issue in the future, but no guarantees on that.