[sle-beta] Transactional Updates in Leap 15
Joe Doupnik
jrd at netlab1.net
Thu Apr 5 07:50:54 MDT 2018
On 05/04/2018 14:32, Thorsten Kukuk wrote:
> On Thu, Apr 05, Joe Doupnik wrote:
>
>> 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.
> Ok, now you perfectly described what transactional updates are doing :)
>
> Thorsten
>
----------
I think we are mixing buzz words and tinkering which may not be
well understood by average system managers, with consequent loss of
confidence and/or interest. To deal with that we (myself included) need
to describe matters in plain candid language which the average sysadmin
can understand and make careful judgements about. We aren't there yet,
again myself included.
The cited doc (worth rereading) does say "transactional" means a
classical ACID approach (retreat from problems). What's missing is all
the other things going on in a fully running system, where backing away
from a change is often not an isolated process (particularly with
coupled systems which involve timestamps etc).
In your previous messages the matter of file system layout comes to
the foreground and is what I have termed advanced detailed planning
which, alas, does not fit well with evolving conditions in the field.
The o/s does not live in splendid isolation from all the rest of the
applications (which are the reason for the o/s to exist). My suggestion
tries to remove such preconditions.
Thus, it is good that we do some preliminary sorting of issues and
come up with understandable and appealing plans.
Thanks,
Joe D.
More information about the sle-beta
mailing list