Talk:Features/OfflineSystemUpdates

From FedoraProject

Revision as of 07:45, 16 June 2012 by Rhughes (Talk | contribs)

Jump to: navigation, search

--Akozumpl 14:08, 15 June 2012 (UTC) :

  • package maintainers who try to test their updated package works now should do that twice, in the regular and in the offline mode.
  • can we get examples of packages that don't update through the regular process and reasons why not?
  • how do people update problematic packages from terminal/non-gnome envs?
  • is there a chance packaging will become more sloppy after this feature is live and we will se increase in a number of packages requiring the offline mode for non-legit reasons?
  • "Note that this feature does not prevent you from using yum to install updates whenever you want to. We also differentiate updates of 'OS components' (which we want to do in this offline fashion) from application updates and installations, which should still be possible from the UI without restarting the system. " I thought Firefox was a driver for this change: is that counted that as an OS component or an application?

--Jnovy 14:38, 15 June 2012 (UTC) :

  • shouldn't there exist an API to even allow rpm/yum to schedule an offline update?
  • if yes, shouldn't there be a lower level mechanism to do that? Not only on PackageKit level?
  • use case: What if future RPM will check if a library to be updated doesn't conflict with library which is currently used by a running binary? If so, RPM could postpone update to Offline updates.

Cwickert 18:06, 15 June 2012 (UTC)
  • Are we actually doing 2 full reboots (incl. BIOS and grub) or will systemd only change to the special update target?
  • How does the differentiation between 'OS components' and applications work?
  • We already have updates that suggest a reboot or log out, but we have a lot of false positives that don't actually require this. How to avoid this in the future?
  • What about reboot vs. log out? We only have reboot available in bodhi.
  • The checkbox in bodhi reads "Suggest Reboot". Will reboot/log out still be suggested or become mandatory? (Read: Will one still be able to update 'OS components' with gkp-update-viewer or only on reboot?
  • How does the system determine if an update requires a reboot or not? How does a package maintainer provide this information?
  • What infrastructure is needed on the server side to provide this information? How is it transported?
  • What happens if one installs updates that are already downloaded and scheduled for installation through yum? Will the menu item disappear and the offline update cache be cleaned?
  • Obviously only PackageKit will be able to understand the reboot requests. Wouldn't it be better to do this on a yum level, say with a plugin, to avoid situations like the one I described?
  • Will downloading updates in the background without user interaction become the default? Will it become configurable or not? Is there a way to avoid unnecessary traffic? Say you are on a train connected through a tethered GPRS installation. In this case you don't want to waste your precious bandwidth for updates, but PackageKit has no way to figure out you are connected only through GPRS.
  • What happens if the system is shutdown while downloading updates in the background? Is there a mechanism to detect broken downloads?
  • Why are updates installed during boot and not while shutting down? An "Install updates and shut down" option makes more sense than reboot because the system is idle anyway (the user is not waiting for it to become available again).
  • What happens with broken updates (testcase 3)? will the complete update fail or will the system behave like --skip-broken?

  • From https://live.gnome.org/GnomeOS/Design/Whiteboards/SoftwareUpdates : "If the app is running it would ask if it is ok to restart the app for you after it installs the update." How is that supposed to work?
  • If the update fails and btrfs snapshot is reverted, how will logs ( http://freedesktop.org/wiki/Software/systemd/SystemUpdates mentions journal) be preserved?
    • Related to that, what changes _not_ caused by the update attempt can happen during the bootup and will be incorrectly reverted? (e.g. AD machine account passwords) - in general, the reverts do sound risky. The first reboot makes it a little better, but still worrying.
  • Bikeshedding - Why isn't the /system-update file in /etc?

--Mitr 18:13, 15 June 2012 (UTC)


Answering some of these questions:

  • package maintainers who try to test their updated package works now should do that twice, in the regular and in the offline mode.

No, why ? The updated package is installed in just the same way. The only difference with offline mode is that there is a reboot before and after the installation of the new packages.

  • can we get examples of packages that don't update through the regular process and reasons why not?
  • how do people update problematic packages from terminal/non-gnome envs?

Not sure I understand these questions. We generally don't ship packages that 'don't update'. The gist of this feature is that by doing the update in the middle of your running system, you end up in a subtly inconsistent state. E.g. if you update a library, all the running applications will still use the old version of the library, while newly started applications will use the new one. Your system will limp along most of the time. Except for when it breaks in mysterious and hard-to-understand ways. The goal of this feature is to eliminate the risk of such breakages.

  • is there a chance packaging will become more sloppy after this feature is live and we will se increase in a number of packages requiring the offline mode for non-legit reasons?

Not a serious question, is it ? In case it is: my answer would be 'no'.

  • "Note that this feature does not prevent you from using yum to install updates whenever you want to. We also differentiate updates of 'OS components' (which we want to do in this offline fashion) from application updates and installations, which should still be possible from the UI without restarting the system. " I thought Firefox was a driver for this change: is that counted that as an OS component or an application?
  • How does the differentiation between 'OS components' and applications work?

I've now put some information about the heuristics for 'OS component' vs application in the feature page.

  • shouldn't there exist an API to even allow rpm/yum to schedule an offline update?
  • if yes, shouldn't there be a lower level mechanism to do that? Not only on PackageKit level?

The API is at the systemd level, can't get much lower than that. If rpm/yum want to grow an 'offline update' mode, they can.

  • use case: What if future RPM will check if a library to be updated doesn't conflict with library which is currently used by a running binary? If so, RPM could postpone update to Offline updates.

PackageKit is doing that today. See CheckSharedLibrariesInUse and UpdateCheckProcesses in /etc/PackageKit/PackageKit.conf

  • Are we actually doing 2 full reboots (incl. BIOS and grub) or will systemd only change to the special update target?
  • Why are updates installed during boot and not while shutting down? An "Install updates and shut down" option makes more sense than reboot because the system is idle anyway (the user is not waiting for it to become available again).

2 reboots. Lennart was in favour of the extra separation we gain by installing updates in a clean, minimal, freshly booted system. And we want to reboot after installing the updates to ensure that all the newly updates components are actually used.

  • We already have updates that suggest a reboot or log out, but we have a lot of false positives that don't actually require this. How to avoid this in the future?
  • What about reboot vs. log out? We only have reboot available in bodhi.
  • The checkbox in bodhi reads "Suggest Reboot". Will reboot/log out still be suggested or become mandatory? (Read: Will one still be able to update 'OS components' with gkp-update-viewer or only on reboot?
  • How does the system determine if an update requires a reboot or not? How does a package maintainer provide this information?
  • What infrastructure is needed on the server side to provide this information? How is it transported?

This feature is not about fine-grained control of when to reboot / logout like these questions seem to assume. We want to broadly say 'OS updates are done offline'. If you know what you are doing and think you don't need to reboot, you can (and most likely already are) just use the commandline.

  • What happens if one installs updates that are already downloaded and scheduled for installation through yum? Will the menu item disappear and the offline update cache be cleaned?

I can't say in detail how the cleaning of the downloaded packages will be organized, but the offline update cache is only put in place when you actually trigger it by hitting 'Restart and install updates' in the menu.

  • Obviously only PackageKit will be able to understand the reboot requests. Wouldn't it be better to do this on a yum level, say with a plugin, to avoid situations like the one I described?

See my answer above - there are no 'reboot requests' per se. PackageKit just uses heuristics to decide how to treat available updates.

  • Will downloading updates in the background without user interaction become the default? Will it become configurable or not? Is there a way to avoid unnecessary traffic? Say you are on a train connected through a tethered GPRS installation. In this case you don't want to waste your precious bandwidth for updates, but PackageKit has no way to figure out you are connected only through GPRS.

Yes, it does have a way. And in fact, gpk-application has had a 'Check for updates when on mobile broadband' option for a long time.

  • What happens if the system is shutdown while downloading updates in the background? Is there a mechanism to detect broken downloads?

Again, not sure if this is a serious question - worst case, the same thing will happen that happens today when you shutdown while yum is downloading updates.

  • What happens with broken updates (testcase 3)? will the complete update fail or will the system behave like --skip-broken?

I don't know this for a fact, but I would assume that we don't pass 'break my system' options like --skip-broken when the goal of the feature is to reduce the potential for updates-induced breakage... --mclasen 00:15, 16 June 2012 (UTC)



Answering some more of these questions:

  • how do people update problematic packages from terminal/non-gnome envs?

You can either use "pkcon update foo --only-download" or use yum to download the packages to a cache and then do /usr/libexec/pk-trigger/offline-update

It's also expected than Daniel will add support for this to Apper, for KDE support.

  • shouldn't there exist an API to even allow rpm/yum to schedule an offline update?

There's a simple API for this, see https://gitorious.org/packagekit/packagekit/blobs/master/contrib/systemd-updates/README.txt for details. I think it's logically on level higher than yum, tho.

  • use case: What if future RPM will check if a library to be updated doesn't conflict with library which is currently used by a running binary? If so, RPM could postpone update to Offline updates.

I don't think that's in the remit of rpm. rpm certainly doesn't want to be doing this process parsing stuff.

  • Are we actually doing 2 full reboots (incl. BIOS and grub) or will systemd only change to the special update target?

The "first" reboot is super quick, and we boot straight into system-update.target. Getting to system-update target and back to rebooting takes me a fraction of a second. Posting the BIOS is the longest bit, but that only takes me a couple of seconds.

  • We already have updates that suggest a reboot or log out, but we have a lot of false positives that don't actually require this. How to avoid this in the future?

We want to do the majority of updates offline, rather than in the running session. It also makes sense from a snapshotting point of view to have as little other stuff running as possible.

  • What about reboot vs. log out? We only have reboot available in bodhi.

At the moment, the new updater appliction doesn't use this data from bodhi at all as most updates are going to be done offline.

  • What happens if one installs updates that are already downloaded and scheduled for installation through yum? Will the menu item disappear and the offline update cache be cleaned?

Yes, a PackageKit plugin clears the prepared-update flag if the user does any update operation manually. It's only reset when the next idle GetUpdates is done, which I think is going to be once a day.

  • Obviously only PackageKit will be able to understand the reboot requests. Wouldn't it be better to do this on a yum level, say with a plugin, to avoid situations like the one I described?

YUM could implement the OfflineOSUpdates thing if it wants, but it was done in PK so to work for all the distros, not just Fedora.

  • Why are updates installed during boot and not while shutting down? An "Install updates and shut down" option makes more sense than reboot because the system is idle anyway (the user is not waiting for it to become available again).

I discussed this on the systemd mailing list, here's the archive: http://lists.freedesktop.org/archives/systemd-devel/2011.../003190.html , TLDR, basically Lennart wants a known-good environment to do the updates in, rather than having dozens of random processes running.

  • What happens with broken updates (testcase 3)? will the complete update fail or will the system behave like --skip-broken?

Updates will fail to be applied, and the prepared-update file will be removed, with an error log written than can be read from the session.

This isn't part of this feature -- it would require more work to other parts of our stack first.

The btrfs snapshot isn't implemented in this feature, so we've not looked at all the details yet. We can't realistically work on the snapshotting until Fedora uses btrfs for / by default.

  • Bikeshedding - Why isn't the /system-update file in /etc?

Lennart wanted it in /, just like the other flags like the selinux relabel flag. IIRC, putting it in root makes the generator easier to write as we're sure the directory is mounted.

--rhughes 07:15, 16 June 2012 (UTC)