[sle-beta] Transactional Updates in Leap 15

[Joe Doupnik]

On 05/04/2018 13:37, Richard Brown wrote:
> On Thu, 2018-04-05 at 13:25 +0100, Joe Doupnik wrote:
>> ---------
>>       The referenced doc is interesting to read and think about. Alas,
>> patching nirvana is still on back-order.
>>       My thinking (yours will likely vary) is as follows. The
>> snapshot-like temp area can be as large as the main o/s file system
>> (root) because we put more into that area than just the o/s and we try
>> to avoid over partitioning etc. Of particular concern is the arrow of
>> time, which means changes occur on the running system after snapping and
>> where also patches will eventually appear. Thus the snapshot becomes out
>> of date after the first such change to the running system. Think about
>> databases, linked systems, memory cached data and the like. Thus a
>> snapshot may not be a safe item to restore in many cases.
> And that problem is addressed by the fact that the root filesystem is read-only in the system role in
> question.
> "The arrow of time" can't change anything, in the root filesystem.
>
> Note, by "root filesystem", we mean the contents of the "root subvolume" on the btrfs partition.
> Any other subvolume is not snapshotted, not considered part of the transactional update, and not read-only.
> This includes (but is not limited to) gems such as /var, /root and /home, where we expect users and services
> to continue their merry tasks of writing nonsense and worthwhile data to those locations.
>
> This division between "the OS root filesystem" and "everything else" is working quite well, hence the
> promotion of this feature from it's previous incarnation only in CaaSP & Kubic, and now suitable for a broader
> audience in Leap and Tumbleweed.
>
>>       What makes more sense to me is patch a quiescent system. That would
>> mean accumulate the new change sets and then bring up the system in
>> memory based rescue mode where the regular file systems is/are otherwise
>> not enabled. The scheme then tries applying patches one by one (with a
>> log to revert), and if a failure occurs then consider undoing them all,
>> with optional variations about accepting some regardless and so forth.
>> This eliminates concerns about open files, memory caches, partial
>> transactions, interaction amongst machines, huge extra disk space, not
>> being restricted to BTRFS, and likely a few more nuances. It also avoids
>> yet another installation-time-only option and thus can be used well
>> after a machine has been built in an ordinary manner.
> This approach would be incredibly long winded. Would users really be willing to have their systems offline for
> so long while they patch so slowly and serially? One of the benefits of our approach is we can patch in a
> threaded manner - every package applies its changeset as fast and as in parallel as the system allows, but
> none of those changes are written to the running snapshot so impacts are avoided until the next reboot.
>
> Doesn't this strike the best balance of using the systems hardware efficiently, minimising downtime, while
> still ensuring updates happen atomicly?
>
     The offline duration part was addressed in my previous message (to 
Thorsten's). It is inherent with changes, and for sensitive situations 
an operational fallback is necessary to cover time and be a safety net.
     Applying changes is still serial process, not parallel (else 
possible disaster and much buggy complexity, see any modern cooperative 
effort for examples). Atomicity/ACID is part of that design, at least as 
much as is reasonable.
     As for efficiency and the like, the least complexity and detailed 
forward planning the better in the field, particularly if such 
configuration needs to be done when first installing a system.
     Thanks,
     Joe D.