State of transactional-update
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 40 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/54425 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
openSUSE Conference 201912 / 40
7
11
12
13
15
16
17
18
19
20
23
25
26
27
34
38
40
00:00
Physical systemSoftware maintenanceSoftware developerProcess (computing)Database transactionWindowPeripheralWater vaporGrand Unified TheoryInteractive televisionIntelligent NetworkProduct (business)Computer animation
00:54
WindowCodecCore dump
01:14
Physical systemService (economics)Electric currentAtomic numberBootingSet (mathematics)Error messageService (economics)Multiplication signOcean currentShared memoryDatabase transactionInheritance (object-oriented programming)Arrow of timeData managementDefault (computer science)Physical systemFile systemBootingSoftwareType theoryProcess (computing)Mobile appMathematicsCASE <Informatik>Exception handlingRead-only memory2 (number)State of matterRollback (data management)Combinational logicComputer fileAtomic numberControl flowInternet service providerFinite-state machineForceLevel (video gaming)Goodness of fitMereologyGame theoryPlastikkarteDistribution (mathematics)Arithmetic meanAirfoilImplementationPatch (Unix)Office suiteLength of stayTouchscreenRobotOperator (mathematics)Hand fanComputer animation
05:32
Computer fileIntegrated development environmentDirectory servicePhysical systemRootkitRollback (data management)Overlay-NetzElectric currentMenu (computing)Default (computer science)Source codeInteractive televisionAsynchronous Transfer Mode2 (number)Directory serviceSinc functionVarianceOffice suiteSoftware developerData managementOpen sourceFile systemMathematicsDigital photographyFigurate numberNumberGroup actionCombinational logicPlotterOverlay-NetzMessage passingBootingInternetworkingComputer fileMetric systemException handlingPhysical systemDatabase transactionMereologyPresentation of a groupBoss CorporationComputer configurationSoftware maintenanceGodParameter (computer programming)Physical lawLetterpress printingMoving averageType theoryCorrespondence (mathematics)Software frameworkWater vaporRevision controlCASE <Informatik>Workstation <Musikinstrument>Cartesian coordinate systemSheaf (mathematics)State of matterCubic graphInteractive televisionInternet service provider1 (number)Software testingSet (mathematics)Open setConfiguration spaceInformation securityPort scannerProfil (magazine)Web pageRootkitAlgorithmServer (computing)Content (media)Link (knot theory)Keyboard shortcutSoftware bugElectronic mailing listRead-only memoryFlow separationMixed realityComputer animation
13:37
Physical systemFile systemDatabase transactionCubic graphRootkitMereologyConfiguration spaceMathematicsContext awarenessDirection (geometry)BootingTouchscreenIsing-ModellLink (knot theory)Mechanism designInformation securityRead-only memoryComputer fileWindowCombinational logicClassical physicsProjective planeMusical ensembleWordWeb browserCuboidAdditionMultiplication signInstallation artWeightMoment (mathematics)Lecture/Conference
16:44
Videoconferencing
Transcript: English(auto-generated)
00:06
My name is Ignaz Foster, I'm a research engineer at SUSE, and I'm the maintainer of transactional updates. So maybe some of you have heard, watched, visited last year's talk at the OpenSUSE conference. So does anybody know what transactional updates are?
00:25
Some of you? Okay, so I'll give a short introduction for the rest of you, and then I'll talk about the new developments which were developed since last year's talk. So as a research engineer, of course, one of my jobs is to also compare with other products,
00:44
and we've seen that Windows is one of those more popular products, and we've tried to see what are the essentials which are popular in Windows, and we've seen that one of those core essences of Windows is it has to reboot constantly.
01:01
So we thought let's also do it on Linux. You don't seem too convinced. So we really tried to do that, but let's see for the real reasons. With regular updates, we currently have a combination of snapper and zipper which are
01:24
operating on a file system, if you're doing a default installation of OpenSUSE. What actually happens is you'll get a new snapshot of your currently running system, then the system is actually updated, and then you get a post snapshot with the new
01:42
state after the installation, so you can roll back if anything you did after the installation destroyed your system. So that's a good mechanic already, but we have one problem. We have that update in the currently running system. So if anything breaks during the update, you have actually destroyed your current
02:04
system and you have to do a rollback to your previous snapshot, but your system is down for that time. So let's try to improve that. There are several distributions, not only OpenSUSE providing transactional updates or atomic updates, how it's occasionally called, which all share that definition of a transactional
02:25
update. A transactional update has to be atomic, so as I just said, it has to either be fully applied or not applied at all, and the update must not influence your currently running system. You don't want to have services restarted during the update or whatever else will happen
02:44
during an update. The second criteria, the update can be rolled back. That's what we already have with our current snapper and super implementation, so that's nothing we have to take care about with transactional updates.
03:02
So what's actually different with transactional updates? We still have our currently running system where that huge red arrow is pointing at, and whenever you are doing an update or any modification done by your package management software and package installation or whatever, you'll get a new snapshot.
03:24
And the update will then run in that new snapshot, so if you type transactional update update up or whatever, pkgn, you get those updates installed into that new snapshot, and the current system doesn't even know of that.
03:43
So it just continues running and running and running, and as soon as you think, oh, the update should now be applied, then you can actually reboot your system. That's the reboot trigger. Why is that? Because a reboot is an atomic thing, you have the guarantee that no process is actually
04:01
running anymore if your system is rebooted, and you can safely boot into that new snapshot then. How is that actually done? Btriff S knows a default snapshot, so if you set, if the update was successful, the new, in that case, green snapshot will be set as the new default snapshot and
04:22
the app will just boot the default Btriff S snapshot. So that's actually what it is. If you want to try transactional update and haven't done it yet, you have a huge chance now if you're using leap 15.0, because the update to leap 15.1 may be one of those
04:48
chances where you have major changes to the system where things may actually break. So you can just install transactional update and it will do the update in the background. You can just ensure everything is going smoothly without destroying your currently running
05:05
system, and if everything goes smoothly, you can just reboot and you're in the new system. That's one use case which you can use. However, there's one exception.
05:21
Sorry, not exception. In that case, you would do that on a read-write file system. Usually you use transactional updates in a read-only file system. I'll tell you about the implications in a few seconds. So let's have a look at the second part, what's new since last year. First of all, we still have our var directory.
05:42
Var is not part of the root file system, so that means that it's also not part of the actual update. If packages try to modify var, you would get changes to your currently running system, which is not what is intended to be done by a transactional update, so that's still
06:02
the case. We won't even bind mount var into the update. If you're a package maintainer, you may have received a bug ticket by us. In the case you did actually modify files in var, those packages would have been incompatible
06:21
with transactional updates, and in the last year we tried to resolve all the remaining packages where var modifications were still done in some postscript or whatever. Currently we know about less than 30 packages which are still doing modifications to var.
06:42
Some of them can't be solved easily because it's an architectural problem, but I think 30 packages out of 12,000 is a quite good ratio, so transactional updates should be considered stable. If we missed something, please tell us. There's an easy way to tell whether an update actually did something which it was not supposed
07:07
to be. Namely, transactional updates will now print out files at the end of the update which would be overmounted. So let's assume a change to var was done, it will print out the corresponding file which
07:23
was changed in var, the same if a file was modified in your home directory or whatever. You'll get a list of those conflicting files which will not be seen in the running system after that. The second thing is ETC handling.
07:40
You may remember if you heard the talk or if you're an active user, on a read-only file system which we usually have with transactional updates, namely in micro S, in cubic, or if you use the transactional server role in open SUSE, Tumblebee, or leap, ETC is mounted
08:01
as an overlay file system. You still want to modify your configuration files. Those overlays are stored in varlib overlays, and the new thing since several months is each of those overlays, sorry, each snapshot gets one separate overlay, or one new overlay.
08:28
You may remember that all the overlays shared one, sorry, all the snapshots shared one common overlay which obviously caused problems when trying to roll back because you then got a mix of new configuration files and old snapshots, so we improved that.
08:48
One interesting thing about those overlays is they are stacked, so if you apply a new update, you'll get that new overlay snapshot which is transparent, and you'll
09:00
see all the lower overlays. I'll show you what that actually means. That's an ETC entry for the ETC mount, and you can see several things here. Obviously, we're currently in snapshot number 18, which is part of the upper there in red, and we have several lower there.
09:21
We had a snapshot 16, 12, 10, 8, 7, 6, and we have the sysroot ETC as the last entry, and you'll just accumulate changes in those overlays. So, if you did something, let's say in overlay number 10, and if you didn't overwrite or change
09:41
that file again in a new overlay, the file will be taken from overlay number 10, so as I said, it's just transparent. If you go down the stack, if you go up the stack, or if you roll back to a previous snapshot, the ETC will only get up until, let's say, snapshot number 12, so newer
10:01
changes won't be visible. Of course, we don't want to have our stack going infinitely, so what we actually did is we implemented a cleanup algorithm. Snapper will occasionally clean up your old snapshots. If the snapshot is not available anymore, you obviously also don't need the overlay
10:24
for it anymore. So, the snapshots will be synced onto the, sorry, the overlay will be synced onto the actual snapshot, but be aware that the state in the snapshot of ETC is not consistent
10:41
or it doesn't represent anything, only the combination of ETC of the snapshot and the overlay stacked on top of each other gives the actual contents of ETC. Yeah, we have a few other things. Oliver contributed a k-exec as a reboot method.
11:02
We have also support for QOD as a reboot daemon now. If you want to use telemetry, you can use Intel's telemetrics. And new, we also have a documentation now. It's the Transactional Update Guide, which can be found on the cubic wiki, the link to
11:26
the Transactional Update Guide, or that's also a link if you want to use the presentation to click on it directly. Another thing that was requested at last year OSC was to get an option to influence
11:43
the behavior of the super run. So we had interactive and non-interactive commands. By default, for example, if you type DAP, which is supposed to be automatic, you always get it in non-interactive mode, and now you can just append the corresponding parameter
12:06
if you think the option is not what you actually want, or if you want to resolve problems manually. If you just want to roll back to a previous good snapshot, you can just type Transactional Update Rollback last now, and your support needs restart now.
12:25
It's a framework for indicating whether the system needs a reboot. If it does, Transactional Update, if any application is using that, Transactional Update will now indicate the correct state.
12:42
So, as I said, you can you have the perfect opportunity to test Transactional Update now with the update from 15 to 15.1. If you're interested in the ETC and VAR behavior, let's say the ETC behavior, there's a very
13:00
interesting talk tomorrow where we will discuss the challenges which the ETC handling has, especially considering the handling or the resetting of states, and we had several talks during this year's conference already. Some of them are the open source talk and the open source desktop talk by Richard,
13:26
and the talk just before this one by Kimlin, why you should choose Open Source Cubic, where you can see Transactional Update in use on those systems. So, that's it, basically. You can find us on cubic.opensource.org.
13:42
Transactional Update is a part of the Cubic project, or you can find us in ISE. The link is below. So, I have, I guess, one minute left, don't I? Any questions? Yes?
14:03
Transactional updates, whether Transactional Updates increase the security of the system? Yes, when combined with the read-only root file system, because then you have the read-only root file system where the data can be changed easily.
14:20
Transactional Update is the only supported update mechanism on read-only root file systems. You can't update it without interfering deeply into the system anyway. So, yes, it's not Transactional Update itself, but the mechanism is behind it. Yeah?
15:07
The question is about salt in combination with configuration.
15:21
Yeah, is it possible to combine configuration changes and package changes at the same time? No, because salt doesn't know about Transactional Updates, so it can't install packages in a correct way. If you are just changing configuration files, that's no problem at all, because configuration
15:41
is dynamic. If salt is only changing them, it can update the configuration. But yes, salt currently doesn't know about installing packages in a Transactional Update context if you are not doing it manually, of course, so that's not possible directly.
16:02
Does that answer your question? Yeah, we should fix it, yes, that's correct.
16:25
Yeah, let's discuss that off screen. Okay. So, that's it from me, basically, and now that we successfully implemented Windows reboot methods, let's start with blue screens next, and thanks, that's my talk.