New subject: [opensuse-factory] Re: OS location (was ANNOUNCE: transactional updates for Tumbleweed)

21 Jan 2017

      Hello,

I would like to announce a new package in Tumbleweed: "transactional-update".

What is this, and why is this from interest for you?

Tumbleweed is a rolling release distribution. Which means, even 
intrusive changes will be applied to a running system, which is
in use by the user.
For a lot of updates this is no problem, but sometimes there are
updates, which make trouble. Only remember the email from
Martin Wilk from Jan 16th, 2017: "CAREFUL: New Tumbleweed snapshot 20170112 released!". Or think about the pam-config update last year.

For another project I wrote a script updating a distribution in a
transactional way. I was asked by many people if I couldn't provide
that for Tumbleweed, too. So, here it is.

What are transactional updates?

A transactioan update:

- is atomic
  - The update does not influence your running system.
  - It's either successful applied or nothing is changed. So no broken
    RPMs are flying around in the system.
- can be rolled back
  - if the upgrade fails or if the update is not compatible, you can
    quickly restore the situation as it was before the upgrade.

What do you need to be able to use it?
- A recent installation of Tumbleweed (updating from older versions,
  especially installations made with openSUSE 13.x, will not work)
  with btrfs and snapshots enabled. If your installation is not
  recent enough, the script will tell and warn you and refuse to work.

How does it work?

In short, we create a snapshot of the system, update this snapshot,
do a "rollback" (or better "somersault") to this new snapshot and with
the next reboot, the updates are there. And if they don't work, boot
the old snapshot and continue to work, until the problem is fixed with
another update.

So, everything is fine?
No, it is not. The original project did work with a read-only root
filesystem. Which means, after taking the snapshot, the original data
couldn't be modified and no data could go lost. With Tumbleweed, all
changes you are doing to the root filesystem subvolume after starting
the script will be lost with the next reboot into the new snapshot.
Which means, after running the script, you should immeaditly reboot
to activate the changes and avoid data lossage.
Modifications in other subvolumes are fine.

Another problem is: we are using snapshots and rollback, so face the
same issues as with snapshots and rollback.
I have run this script now for three month on a default Tumbleweed
installation by cron without any problems. But there are RPMs, which
will create problems, and which needs to be adjusted.
1. strictly seperate code from user data. /srv is a real nightmare.
   Either user data will go lost, or the application will not be
   updated or rolled back.
2. Don't modify data in post install sections, but during boot or
   first start instead. If the data is in a subvolume, this one will
   not be accessible during the upgrade. Or the update wouldn't be
   atomic anymore.
3. Don't create something outside the snapshot subvolume, this
   will not survive the next reboot.
4. RPM, which installs directories or data into directories, which
   are subvolumes, needs to be adjusted. This will not work.
   Example: /var/cache is an own subvolume. Quite some RPMs
   create directories and data there, and some of them will stop
   working if you remove this directories.
   That's bad even without transactional updates, a system
   administrator should always be allowed to delete the cache.
   A better way is to create the directories during boot with
   tmpfiles.d(5).
   Same problem for all other subvolumes like /var/log, /var/spool,
   etc.

So, now you can test the script and I hope it is from use for many
of you. I'm pretty sure there are still situations which the script
cannot handle, and a lot of you have ideas about how to improve it.
I'm happy about every patch or idea. And of course adjusted RPMs,
which have no problem with this update method.

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
-- 
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

[opensuse-factory] ANNOUNCE: transactional updates for Tumbleweed

tags

participants (17)