Mailinglist Archive: opensuse-features (25 mails)

< Previous Next >
[openFATE 312799] Safer distribution updates
Feature changed by: Thorsten Kukuk (kukuk)
Feature #312799, revision 20
Title: Safer distribution updates

Requested by: Michael Schröder (mlschroe)
Partner organization: openSUSE.org

Description:
Currently the documentation says that to do a distribution upgrade you
should first update your software stack to the target distribution,
then do a zypper dup. The software stack update can already kill your
system.
zypper could allow an option that makes it first install a miniroot
containing the update stack itself, then automatically switch over to
the miniroot to do the "zypper dup".

Relations:
- On-line migration between service packs (feature/id: 315161)

Use Case:
Bob wants to migrate his server from SLE12 to SLE13 (or from SP1 to
SP2). Upgrading the package management stack fails, but he keeps his
original system untouched.
Joe wants to migrate his desktop from openSUSE 12.1 to 12.2.

Business case (Partner benefit):
openSUSE.org: Failsafe migrations for SLE

Discussion:
#1: Joachim Werner (joachimwerner) (2013-08-06 20:06:57)
If we decide to actually allow "online" zypper dup on SLE 12 this is
indeed mandatory. In case the decision is made that we should always
boot into an update system for a distribution update, this is still
nice to have for openSUSE, but would be downgraded for SLE.

#2: Jiri Srain (jsrain) (2013-08-28 09:48:49)
We don't intend to support 'zypper dup' updates from SLE11 to SLE12.
The service pack migration (which is the only case for the on-line
migration) is being handled as separate features and the discussion may
have quite different results (based on the channel set-up).
One of the ideas for on-line migration indeed was to boot SP-new system
to perform the migration itself, as documented in Fate#315161.
Because of the above, I suggest to reject (not meaning that the request
is invalid).

#4: Anja Stock (neyleah) (2015-02-05 15:13:03)
Can you please agree on one product here and copy if needed for 2
products, so we can track that separately?

#5: Joachim Werner (joachimwerner) (2015-04-08 12:52:22)
Making this an SP1-only feature. Of course the expectation is that any
improvement in zypper for 12 SP1 will also be rolled into openSUSE as a
matter of policy.

#6: Jiri Srain (jsrain) (2015-04-15 10:54:20) (reply to #5)
We agreed that for SP upgrade we will first update the update stack
from the _old_ repositories - it will be known to work in the old
system as well as support new packages.
What's requested beyond this from this feature?

#7: Joachim Werner (joachimwerner) (2015-04-15 11:18:59) (reply to #6)
I have no experience how often the zypper update would actually cause
problems, and given that we now offer btrfs snapshots, maybe the
problem Michael describes isn't that bad after all.
But always running the update stack from a miniroot would definitely
provide one more layer of safety and allow us to introduce more new
stuff during distribution update than we can with the conservative
approach.
Ultimately an engineering decision, but I'd like to keep this at least
important for SP1.

#8: Joachim Werner (joachimwerner) (2015-04-15 11:19:55)
PM Priority for product SLES-12-SP1 downgraded from mandatory to
important:
Reconsidered importance, given that we now have btrfs snapshots that
allow relatively painless rollbacks.

#9: akash vishwakarma (vish_99) (2015-05-05 10:48:16) (reply to #8)
Joachim if wanted to reject the feature you could have rejected it by
editing the product and should have given reason explaining reason why
you rejected the feature. Instead of deleting the project itself.

#11: Joachim Werner (joachimwerner) (2015-05-26 16:20:38) (reply to
#9)
Hi, I didn't want to confuse anybody, but given that this was a request
created internally by a SUSE employee in the first place and that we
shouldn't have requests for both openSUSE and SLES in the same FATE I
thought that removing openSUSE was the most straightforward change.

#10: akash vishwakarma (vish_99) (2015-05-05 11:31:05)
In order to avoid confusion that why product is missing. Adding
openSUSE distribution as product and rejecting it.

+ #12: Thorsten Kukuk (kukuk) (2015-11-24 14:15:37)
+ Joe, since you added SLES12 SP2, what do you expect from us here?
+ This feature is not needed for SP migration (would be in violation with
+ PM requirements for SP migration) and we don't know anything about
+ SLE13, so there is nothing we can implement to support that.




--
openSUSE Feature:
https://features.opensuse.org/312799

< Previous Next >
This Thread