October 2010 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 309839] rss only for new entries
by fate_noreply＠suse.de 27 Oct '10

27 Oct '10

Feature added by: Boris Churzin (essl) Feature #309839, revision 1 Title: rss only for new entries openFATE: Unconfirmed Priority Requester: Important Requested by: Boris Churzin (essl) Description: Current public rss includes all the changes in openFATE, which is pretty much useless IMO. For most users it would be much more interesting to get only the new entries, so they can vote on them. -- openSUSE Feature: https://features.opensuse.org/309839

1 1

[New: openFATE 310091] Ability to view features I have commented on
by fate_noreply＠suse.de 27 Oct '10

27 Oct '10

Feature added by: Ilya Chernykh (Ansus) Feature #310091, revision 1 Title: Ability to view features I have commented on openFATE: Unconfirmed Priority Requester: Important Requested by: Ilya Chernykh (ansus) Description: I see no possibility to re-visit features I have commented on and check if there any replies. I tried to make search by my nickname, but got not results. -- openSUSE Feature: https://features.opensuse.org/310091

1 1

[New: openFATE 310302] Adding openSUSE medical
by fate_noreply＠suse.de 27 Oct '10

27 Oct '10

Feature added by: Sascha Manns (saigkill) Feature #310302, revision 1 Title: Adding openSUSE medical openFATE: Unconfirmed Priority Requester: Neutral Requested by: Sascha Manns (saigkill) Description: The openSUSE medical team requests a entry in openFATE's Products like "openSUSE medical". So we can collect new ideas into the FATE System. -- openSUSE Feature: https://features.opensuse.org/310302

1 1

[openFate 305690] Replace System-V init with upstart init
by fate_noreply＠suse.de 27 Oct '10

27 Oct '10

Feature added by: Vitaliy Tomin (HighwayStar) Feature #305690, revision 1, last change by Title: Replace System-V init with upstart init openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Vitaliy Tomin (highwaystar) Partner organization: openSUSE.org Description: Upstart - an event-based init daemon. It can provide more flexible init system for more faster and effective boot and communication with the init daemon over D-Bus. upstart home page http://upstart.ubuntu.com/ -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305690

1 56

[New: openFATE 308621] file sharing like DropBox/Ubuntu One
by fate_noreply＠suse.de 27 Oct '10

27 Oct '10

Feature added by: Frank Bechstein (currios) Feature #308621, revision 1 Title: file sharing like DropBox/Ubuntu One openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Frank Bechstein (currios) Description: File sharing Service like Ubuntu One. -- openSUSE Feature: https://features.opensuse.org/308621

1 17

[openFATE 306341] Show developer assigned information
by fate_noreply＠suse.de 26 Oct '10

26 Oct '10

Feature added by: Michael Löffler (michl19) Feature #306341, revision 1, last change by Title: Show developer assigned information openFATE: Unconfirmed Priority Requester: Important Requested by: Michael Löffler (michl19) Description: Currently its not visible for community outside Novell if a developer is set or not. To ease community conribution this information needs to be visible outside the company as well. People then can find features where help is needed much easier and/or a call for contribution can be made. -- openSUSE Feature: https://features.opensuse.org/306341

1 8

[openFATE 310669] Automatic dependency resolution for kiwi product builds
by fate_noreply＠suse.de 25 Oct '10

25 Oct '10

Feature changed by: Stephan Kulow (coolo) Feature #310669, revision 4 Title: Automatic dependency resolution for kiwi product builds Buildservice: New Priority Requester: Important Requested by: Christoph Thiel (cthiel1) Requested by: Stephan Kulow (coolo) Description: For products like the SDK, it would be great to have automatic dependency resolution for kiwi product builds. This could for example be based on patterns available on that product. In addition to that, some kind of "meta description" for a products package list would be helpful: e.g. all packages needed for rebuilding product X and Y (SLES and SLED) - minus a list of package + another list of additional packages (as defined in patterns). So far, this "meta description" of the SDK has been tracked outside of the product builds in external scripts, which has been quite tedious at times. Discussion: #1: Adrian Schröter (adriansuse) (2010-10-21 11:06:16) Just learned that coolo wants this also openSUSE. + #2: Stephan Kulow (coolo) (2010-10-25 12:09:10) (reply to #1) + Christoph used to use a set of scripts on top of mine. -- openSUSE Feature: https://features.opensuse.org/310669

1 0

[openFATE 308626] Snapshot/Rollback interface to the ZYpp stack
by fate_noreply＠suse.de 22 Oct '10

22 Oct '10

Feature changed by: Olaf Kirch (okir) Feature #308626, revision 25 Title: Snapshot/Rollback interface to the ZYpp stack openSUSE-11.3: Evaluation Priority Requester: Mandatory openSUSE-11.4: Evaluation Priority Requester: Important Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) Requested by: Duncan Mac-Vicar (dmacvicar) Developer: (Novell) Developer: (Novell) Partner organization: openSUSE.org Description: Ability for libzypp and exposed via zypper to snapshot either automatically or explicitly the system before commit happens, plus an interface to revert the system. The interface should be generic and allow for different possible implementations which should be offered depending on the context: * btrfs based if /root is btrfs * simple based on package list before commit, plus package history and current package list to determine diff last transaction * two root partitions, where the interface would clone root filesystem before commit and switch them at rollback time. The feature includes the concept, and a working implementation with one or more of the strategies described before. References: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs http://dev.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autou… http://wiki.rpath.com/wiki/Conary:conary_rollback Relations: - grub1 patch for btrfs boot (url: ) Documentation Impact: Requires description of the functionality in zypper options Test Case: zypper install foo bar zypper rollback System should be as before the installation. Corner cases are not important. Use Case: Administrator installs a bunch of updates, which leaves the system in an an unworkable state. He types zypper rollback to undo the changes. Business case (Partner benefit): openSUSE.org: * Customer asked about snapshoting during our last meeting. * Feature parity with Solaris which is implementing package rollback based on ZFS * RHEL goes the same route, announced btrfs rollbacks in yum * We can do better, offering something more flexible and not btrfs dependent to support different scenarios: SLES (btrfs), Appliances (dual system partition), openSUSE (simple package list) Discussion: #1: Federico Lucifredi (flucifredi) (2010-03-05 07:29:41) PM: Important for 11.3. (sorry, on web client). #3: Joachim Werner (joachimwerner) (2010-04-28 18:10:50) I have SLEPOS-specific use cases for this feature, too. IBM implemented a similar rollback feature in IRES2, based on tripwire AFAIK. Some techical considerations we need to understand: Rolling back the right things What customers really want is not a dumb rollback of everything on the system to the old state, but just the changes done by the update. So it may be necessary to make sure the snapshot only applies to the configuration directories (usually /etc) and the code directories (/usr) affected by the update, but not things like logfiles (which should be continuous) or application data (nobody wants to get their database files rolled back by accident, or data a user has saved in /home/username in the meantime). Another potential issue with some applications is that they can be in an inconsistent state if they aren't stopped during a snapshot. This is a more generic problem with snapshots as such. For this Windows has mechanisms to inform an application that it's going to do a shadow copy now. In Linux there is no single interface to trigger that, although some databases and other applications have there own way of switching into a read-only snapshotting-safe mode. So, this is all doable, but just applying a system-wide snapshot seems to be too simple. Maybe we can just copy what Red Hat is doing here (if it's good enough). Red Hat has finished this feature in Fedora, and it's probably going to be in RHEL6 at some point, too. https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs (https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs) contains a few considerations on this. Avoiding situations that can't be recovered zypper rollback sounds like a good plan at first, but it is not in all cases. If you apply an update that breaks the system, this could mean that a kernel update went wrong and you can't even boot beyond a certain stage. So there needs to be a way of entering the recovery from the earliest possible level, the boot prompt. There needs to be an option to boot into the snapshotted system, and from there eliminate the changes made after the snapshot and declare the snapshot to be the current state. For the worst case (a broken grub package or so kills the bootloader configuration) we need to have a recovery workflow (from CD or so) that can still bring back the old working state. Do one thing right, not three things that solve the same problem If we decide to go down the btrfs route (which I like) we should not also solve the same problem using several other approaches. Why use dual system partitions if you can have snapshots? #7: Duncan Mac-Vicar (dmacvicar) (2010-10-21 10:43:26) I would like to clarify some issues: For rollbacks, it would be the ideal situation to have the root filesystem completely under btrfs, otherwise you run into the problem that kernels are not affected by the rollback and this increases complexity. * a) For this we need to boot with btrfs. Matthias told me we should ignore this problem because under EFI you have to put the kernel under /efi in a FAT partition, but my own research tells me that what is in FAT /efi is the grub EFI program, and therefore the kernel could be in btrfs if the grub EFI program supports finding the kernel with btrfs. Can anyone confirm this? * b) For booting with btrfs we need either grub2, or syslinux or a patch for grub1 (added as a reference to the feature). Which route will we follow here? Do we have anyone empowered to make this decision soon? * c) if b) is solved with grub1 patch I suggest we open a feature entry to track that one. + #9: Olaf Kirch (okir) (2010-10-22 12:56:49) (reply to #7) + My preferred solution would be to enable grub1 for btrfs; it seems to + pose the least risk - assuming the btrfs code is stable enough. (BTW + either my fate client is too old, or the link you added is broken). -- openSUSE Feature: https://features.opensuse.org/308626

1 0

[New: openFATE 310693] Include version information in XML stream
by fate_noreply＠suse.de 22 Oct '10

22 Oct '10

Feature added by: Lars Vogdt (lrupp) Feature #310693, revision 1 Title: Include version information in XML stream Buildservice: New Priority Requester: Desirable Requested by: Lars Vogdt (lrupp) Description: To avoid people using outdated OBS clients (like osc), it might be a good idea to include a "obs-version" number in the results of a request, so the clients can print out some warnings if the obs-version is too new for them (or even incompatible). -- openSUSE Feature: https://features.opensuse.org/310693

1 3

[openFATE 308626] Snapshot/Rollback interface to the ZYpp stack
by fate_noreply＠suse.de 21 Oct '10

21 Oct '10

Feature changed by: Matthias Eckermann (mge1512) Feature #308626, revision 23 Title: Snapshot/Rollback interface to the ZYpp stack openSUSE-11.3: Evaluation Priority Requester: Mandatory openSUSE-11.4: Evaluation Priority Requester: Important Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) + Info Provider: (Novell) Requested by: Duncan Mac-Vicar (dmacvicar) Developer: (Novell) Developer: (Novell) Partner organization: openSUSE.org Description: Ability for libzypp and exposed via zypper to snapshot either automatically or explicitly the system before commit happens, plus an interface to revert the system. The interface should be generic and allow for different possible implementations which should be offered depending on the context: * btrfs based if /root is btrfs * simple based on package list before commit, plus package history and current package list to determine diff last transaction * two root partitions, where the interface would clone root filesystem before commit and switch them at rollback time. The feature includes the concept, and a working implementation with one or more of the strategies described before. References: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs http://dev.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autou… http://wiki.rpath.com/wiki/Conary:conary_rollback Relations: - grub1 patch for btrfs boot (url: ) Documentation Impact: Requires description of the functionality in zypper options Test Case: zypper install foo bar zypper rollback System should be as before the installation. Corner cases are not important. Use Case: Administrator installs a bunch of updates, which leaves the system in an an unworkable state. He types zypper rollback to undo the changes. Business case (Partner benefit): openSUSE.org: * Customer asked about snapshoting during our last meeting. * Feature parity with Solaris which is implementing package rollback based on ZFS * RHEL goes the same route, announced btrfs rollbacks in yum * We can do better, offering something more flexible and not btrfs dependent to support different scenarios: SLES (btrfs), Appliances (dual system partition), openSUSE (simple package list) Discussion: #1: Federico Lucifredi (flucifredi) (2010-03-05 07:29:41) PM: Important for 11.3. (sorry, on web client). #3: Joachim Werner (joachimwerner) (2010-04-28 18:10:50) I have SLEPOS-specific use cases for this feature, too. IBM implemented a similar rollback feature in IRES2, based on tripwire AFAIK. Some techical considerations we need to understand: Rolling back the right things What customers really want is not a dumb rollback of everything on the system to the old state, but just the changes done by the update. So it may be necessary to make sure the snapshot only applies to the configuration directories (usually /etc) and the code directories (/usr) affected by the update, but not things like logfiles (which should be continuous) or application data (nobody wants to get their database files rolled back by accident, or data a user has saved in /home/username in the meantime). Another potential issue with some applications is that they can be in an inconsistent state if they aren't stopped during a snapshot. This is a more generic problem with snapshots as such. For this Windows has mechanisms to inform an application that it's going to do a shadow copy now. In Linux there is no single interface to trigger that, although some databases and other applications have there own way of switching into a read-only snapshotting-safe mode. So, this is all doable, but just applying a system-wide snapshot seems to be too simple. Maybe we can just copy what Red Hat is doing here (if it's good enough). Red Hat has finished this feature in Fedora, and it's probably going to be in RHEL6 at some point, too. https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs (https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs) contains a few considerations on this. Avoiding situations that can't be recovered zypper rollback sounds like a good plan at first, but it is not in all cases. If you apply an update that breaks the system, this could mean that a kernel update went wrong and you can't even boot beyond a certain stage. So there needs to be a way of entering the recovery from the earliest possible level, the boot prompt. There needs to be an option to boot into the snapshotted system, and from there eliminate the changes made after the snapshot and declare the snapshot to be the current state. For the worst case (a broken grub package or so kills the bootloader configuration) we need to have a recovery workflow (from CD or so) that can still bring back the old working state. Do one thing right, not three things that solve the same problem If we decide to go down the btrfs route (which I like) we should not also solve the same problem using several other approaches. Why use dual system partitions if you can have snapshots? #7: Duncan Mac-Vicar (dmacvicar) (2010-10-21 10:43:26) I would like to clarify some issues: For rollbacks, it would be the ideal situation to have the root filesystem completely under btrfs, otherwise you run into the problem that kernels are not affected by the rollback and this increases complexity. * a) For this we need to boot with btrfs. Matthias told me we should ignore this problem because under EFI you have to put the kernel under /efi in a FAT partition, but my own research tells me that what is in FAT /efi is the grub EFI program, and therefore the kernel could be in btrfs if the grub EFI program supports finding the kernel with btrfs. Can anyone confirm this? * b) For booting with btrfs we need either grub2, or syslinux or a patch for grub1 (added as a reference to the feature). Which route will we follow here? Do we have anyone empowered to make this decision soon? * c) if b) is solved with grub1 patch I suggest we open a feature entry to track that one. -- openSUSE Feature: https://features.opensuse.org/308626

1 0