Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #312799, revision 4 Title: Safer distribution updates openSUSE Distribution: New Priority Requester: Desirable Requested by: Michael Schröder (mlschroe) - Product Manager: Michael Elliott (mge) 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". Use Case: Bob wants to migrate his server from SLE12 to SLE13. Upgrading the package management stack fails, but he keeps his original system untouched. Business case (Partner benefit): openSUSE.org: Failsafe migrations for SLE -- openSUSE Feature: https://features.opensuse.org/312799

Feature changed by: Joachim Werner (joachimwerner) Feature #312799, revision 9 Title: Safer distribution updates openSUSE Distribution: Evaluation by project manager Priority Requester: Mandatory 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". 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. -- openSUSE Feature: https://features.opensuse.org/312799

Feature changed by: Anja Stock (Neyleah) Feature #312799, revision 12 Title: Safer distribution updates openSUSE Distribution: Evaluation by product manager Priority Requester: Mandatory 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? -- openSUSE Feature: https://features.opensuse.org/312799

Feature changed by: Jiri Srain (jsrain) Feature #312799, revision 14 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? -- openSUSE Feature: https://features.opensuse.org/312799

Feature changed by: akash vishwakarma (vish_99) Feature #312799, revision 17 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. + #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. -- openSUSE Feature: https://features.opensuse.org/312799

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

Feature changed by: Thorsten Kukuk (kukuk) Feature #312799, revision 22 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. #13: Jiri Srain (jsrain) (2015-11-25 10:24:51) (reply to #12) As a side note: For SLE12 SP-migraiton (let's take GA->SP1 here in order to be able to use specific versions) we perform the migration with update stack coming from GA. It is provided as a regular maintenance update and thus should be well tested and not break anything (should be perfectly compatible with GA). It is IMO safe enough to backport needed functionality from SP1 to GA, compared to running update stack, which is possibly not compatible with GA. If we want to target upgrade from 12 to 13, it would be a different challenge, though. + #14: Thorsten Kukuk (kukuk) (2015-12-01 15:33:05) + "Currently the documentation says that to do a distribution upgrade you + should first update your software stack to the target distribution" + Michael, where is this written in the documentation? This is clearly + wrong and needs to be fixed. Updating the update stack first to the + target distribution should never be necessary. -- openSUSE Feature: https://features.opensuse.org/312799

Feature changed by: Jiri Srain (jsrain) Feature #312799, revision 24 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. #13: Jiri Srain (jsrain) (2015-11-25 10:24:51) (reply to #12) As a side note: For SLE12 SP-migraiton (let's take GA->SP1 here in order to be able to use specific versions) we perform the migration with update stack coming from GA. It is provided as a regular maintenance update and thus should be well tested and not break anything (should be perfectly compatible with GA). It is IMO safe enough to backport needed functionality from SP1 to GA, compared to running update stack, which is possibly not compatible with GA. If we want to target upgrade from 12 to 13, it would be a different challenge, though. #14: Thorsten Kukuk (kukuk) (2015-12-01 15:33:05) "Currently the documentation says that to do a distribution upgrade you should first update your software stack to the target distribution" Michael, where is this written in the documentation? This is clearly wrong and needs to be fixed. Updating the update stack first to the target distribution should never be necessary. #15: Jiri Srain (jsrain) (2015-12-23 16:22:26) (reply to #14) I agree. With SLE12 SP migration (taking GA to SP1 as example here) we use the GA update stack during the migration. The miniroot has the drawback that one would need to bind-mount the initial root under this mini-root to have it accessible from chroot. The behavior of all post-install scripts, especially when touching running services (running out of hte chroot) is something that sounds very fragile. We have already had some fun with YaST installer in regards in which of the two roots D-Bus is running, this would add 3rd level. Joachim (or Hannes), please, reject. + #16: Jiri Srain (jsrain) (2016-01-06 11:14:41) (reply to #15) + Returning to PM (resoning in previous comments) -- openSUSE Feature: https://features.opensuse.org/312799

Feature changed by: Oliver Kurz (okurz) Feature #312799, revision 26 - Title: Safer distribution updates + Title: Safer distribution upgrades with update of software management + stack in miniroot first 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) + - Easy Upgrade (feature/id: 313441) 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. #13: Jiri Srain (jsrain) (2015-11-25 10:24:51) (reply to #12) As a side note: For SLE12 SP-migraiton (let's take GA->SP1 here in order to be able to use specific versions) we perform the migration with update stack coming from GA. It is provided as a regular maintenance update and thus should be well tested and not break anything (should be perfectly compatible with GA). It is IMO safe enough to backport needed functionality from SP1 to GA, compared to running update stack, which is possibly not compatible with GA. If we want to target upgrade from 12 to 13, it would be a different challenge, though. #14: Thorsten Kukuk (kukuk) (2015-12-01 15:33:05) "Currently the documentation says that to do a distribution upgrade you should first update your software stack to the target distribution" Michael, where is this written in the documentation? This is clearly wrong and needs to be fixed. Updating the update stack first to the target distribution should never be necessary. #15: Jiri Srain (jsrain) (2015-12-23 16:22:26) (reply to #14) I agree. With SLE12 SP migration (taking GA to SP1 as example here) we use the GA update stack during the migration. The miniroot has the drawback that one would need to bind-mount the initial root under this mini-root to have it accessible from chroot. The behavior of all post-install scripts, especially when touching running services (running out of hte chroot) is something that sounds very fragile. We have already had some fun with YaST installer in regards in which of the two roots D-Bus is running, this would add 3rd level. Joachim (or Hannes), please, reject. #16: Jiri Srain (jsrain) (2016-01-06 11:14:41) (reply to #15) Returning to PM (resoning in previous comments) #17: Hannes Kühnemund (hkuehnemund) (2016-01-07 11:07:37) PM Priority for product SLES-12-SP2 downgraded from mandatory to important: See comment #15. #18: Hannes Kühnemund (hkuehnemund) (2016-01-07 11:07:46) PM Priority for product SLES-12-SP2 downgraded from mandatory to neutral: See comment #15. -- openSUSE Feature: https://features.opensuse.org/312799