May 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 302963] Rating support for FATE
by fate_noreply＠suse.de 30 May '09

30 May '09

Feature changed by: Rajko Matovic (rajko_m) Feature #302963, revision 23 Title: Rating support for FATE openFATE: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: FATE is becoming a huge database of useless information. Most of this come to the fact that there is only syntantic checking but not social checking. Usecase: Searching and navigating produces lot of: * Duplicate features * Incomplete features (no use cases, examples) * Vague features (a.k.a "#xxxxx YaST should be improved" ) * copy and paste features Features should support rating in the slashdot way (Insightful, Interesting, Informative, Troll, Funny) and rating from 1 to 5. The rating could be used so the same people using FATE could score down low- quality features than only make the process of information flow more difficult. Score threshold could be set by people so only high quality, well specified features are shown. It is important that searching could be done using this ratings. It should be possible to generate rankings over this ratings. Current status FATE does not offer anything to filter low quality features User Experience Query dialog would gain an option for searching. Feature editor would gain a rating dialog where different people would express their rating. Search would be over an average or agregation of this scores. Scores should be saved per rater. Contingency Plan No contingency plan at the software level. At the process level, add comments to every feature lacking business case, detailed description, real benefits, and more important, scope. Documentation Impact: Only needs to be mentioned in the handbook. Test Case: * rate a feature in one or two dimensions (score and category) * search for features >= or <= certain rating Business case (Partner benefit): openSUSE.org: Threshold for feature processing should save thousands of dollars in wasted time doing ping pong, needinfos for features with incomplete information. Even engineering could be optimized when features with no real business case dissapear by social tagging. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2008-04-02 01:26:51) Sounds like an interesting idea for openSUSE. I am looking forward towards considering this for some Phase 2 or so once openFATE (or whatever the name is going to be) is up and running. #3: Stephan Binner (beineri) (2009-01-17 16:03:07) (reply to #1) openFATE is now up and running. Can this request be made public to openSUSE.org partner? #2: Gerald Pfeifer (geraldpfeifer) (2008-11-14 18:05:55) Michl, for the openFATE work. (For SLE, I expect the PMs to take on much of this.) #4: Francis Giannaros (apokryphos) (2009-01-28 16:04:18) This would be great to see. For reference, see https://blueprints.launchpad.net/ubuntu with some good ideas. Also a tag cloud like the build service has might be nice. #5: Andre Duffeck (aduffeck) (2009-01-28 16:14:23) (reply to #4) We will release a new openFATE version by the end of the week with both voting and tagging support (including a cloud ;)) #7: Francis Giannaros (apokryphos) (2009-01-30 20:29:40) (reply to #5) Awesome! #6: Thomas Schmidt (digitaltomm) (2009-01-30 15:12:39) Rating features is available now in openfate with the three options -0 +. Searching for features with or above a certain score is not yet there. Do we need to integrate the voting and search by rating stuff in the FATE client or is this just a community feature? #8: Stephan Binner (beineri) (2009-01-31 11:46:14) (reply to #6) Can you please add a voting column to the browse/query result list and allow sorting by it? Atm you seem to be only able to view the top 5 voted requests (on the dashboard). #10: Michael Löffler (michl19) (2009-02-02 11:35:31) (reply to #8) Yes, it would be useful to see the score already while brosing through the features. #9: Michael Löffler (michl19) (2009-02-02 11:34:32) (reply to #6) Voting is not necessary for the internal client. Internal features should be more driven by use case and business case. For openFate the public opinion is more important to know. But the voting score of external features should be displayed internally. #11: Klaas Freitag (kfreitag) (2009-05-06 16:41:29) (reply to #6) I think what the currently implemented rating is a kind of value for "public interest" but not so much about the quality of a feature. How I understand this featurerequest it is about how helpful, interesting and complete a feature is. I think it would be good to have this kind of rating because that helps people to learn what good features are and hopefully improves the overall quality of the FATE contents. The only downside I see is that there are too many different "ratings" and users get confused. + #12: Rajko Matovic (rajko_m) (2009-05-30 14:29:43) (reply to #11) + It seems somewhat elitistic and inconsisten with openFATE idea that + "public interest" is not the most important quality of the requested + feature. Although there is a problem with current status of voting, it + is now one way street, like in polls, you vote and forget. When someone + adds comment that might change public opinion, there is no way for + openFate users to change their vote, and all previous votes may, or may + not have meaning, depends on the nature of added comment. -- openSUSE Feature: https://features.opensuse.org/302963

1 0

[openFATE 305885] Handle the metadata "dirty" bit when an ISW array contains the root file system
by fate_noreply＠suse.de 29 May '09

29 May '09

Feature changed by: Marc Ruehrschneck (macrue) Feature #305885, revision 8 Title: Handle the metadata "dirty" bit when an ISW array contains the root file system openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Marc Ruehrschneck (macrue) - Partner organization: Intel + Partner organization: openSUSE.org Description: Shutdown scripts need to wait until all the MDRAID arrays are marked clean: The dirty bit dictates whether an array needs to be resynced. The OS must block writes to the array until the dirty bit is set, and it should allow for the bit to be cleared as a part of the system shutdown process. For rootfs-raid the metadata handler will need to be started in the early userspace environment as even mounting the root- filesystem read-only may cause writes to be issued due to journal recovery. This involves including mdmon in the initrd and and using the "--switch-root" option to switch the monitor to the final rootfs environment. At shutdown the OS must allow for the metadata handler to stay running across the "mark root-filesystem readonly" event, i.e. it must be excluded from the general killall events. Once all filesystems are readonly a call to "mdadm --wait-clean --scan" will quiesce all writes and clear the metadata dirty bit. Business case (Partner benefit): - Intel: Enable feature parity with the Windows IMSM stack for Linux - customers + openSUSE.org: Enable feature parity with the Windows IMSM stack for + Linux customers -- openSUSE Feature: https://features.opensuse.org/305885

1 0

[openFATE 305883] Install and boot support for MDRAID External Metadata (ISW)
by fate_noreply＠suse.de 29 May '09

29 May '09

Feature changed by: Michael Löffler (michl19) Feature #305883, revision 8 Title: Install and boot support for MDRAID External Metadata (ISW) openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Marc Ruehrschneck (macrue) - Partner organization: Intel + Partner organization: openSUSE.org Description: Support for MDRAID External Metadata ISW for raid 0, 1, 10 and 5, 6 (??). User should have a choice between DMRAID and MDRAID or have no DMRAID support. This feature request has three aspects: 1) Detection of RAID arrays and platform capabilities Currently SLES can detect raid arrays but it does not confirm whether raid is enabled in the platform BIOS. If raid support has been disabled in the BIOS then arrays should not be presented as candidates for installation Currently "mdadm --detail-platform -e imsm" could be used for this detection as it returns true when the platform has Intel(R) Matrix Storage Manager support enabled. 2) Creating an initrd with support for assembling ISW raid arrays This has dependencies on how FR#781 is resolved (mdp versus kpartx) and needs support for handling the metadata dirty bit FR#782. At a minimum it involves adding something akin to the following commands to the initrd init script: ... mdadm -Asc mdadm.conf mount /dev/md/Volume0p1 /sysroot mdmon --switch-root /sysroot /dev/md/imsm0 ... 3) Installing the bootloader on a RAID device Fortunately the version of grub in SLES11-beta6 seems to already understand/expect partitionable md arrays as the following grub commands: root (hd0,0) setup (hd0) ...ends in a failure to access /dev/md/Volume0p1. So this may add weight to the mdp case for FR#781. Adding a link to the kpartx partition, that SLES11 currently creates, allows this to grub installation to complete successfully. However, this required hand editing of /boot/grub/device.map so the final solution will probably require a utility to dump the grub device to raid device mapping, or the restriction that the raid device must be grub device (hd0). Business case (Partner benefit): - Intel: Enable feature parity with the Windows IMSM stack for Linux - customers + openSUSE.org: Enable feature parity with the Windows IMSM stack for + Linux customers -- openSUSE Feature: https://features.opensuse.org/305883

1 0

[openFATE 305886] SGPIO support for MD
by fate_noreply＠suse.de 29 May '09

29 May '09

Feature changed by: Michael Löffler (michl19) Feature #305886, revision 11 Title: SGPIO support for MD - openSUSE-11.2: Rejected by Stephan Kulow (coolo) - reject date: 2009-05-20 13:21:33 - reject reason: out of focus for 11.2 + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Marc Ruehrschneck (macrue) - Partner organization: Intel + Partner organization: openSUSE.org Description: md-sgpio application is a standalone application that monitors raid arrays via sysfs. Events shall trigger LED change request via a sgpio application Business case (Partner benefit): - Intel: Enable feature parity with the Windows IMSM stack for Linux - customers + openSUSE.org: Enable feature parity with the Windows IMSM stack for + Linux customers Discussion: #4: Michael Löffler (michl19) (2009-05-27 18:56:36) (reply to #3) I wonder here as well. If not in openSUSE where is the place for upstream devlopment. And I wonder if we can open up the feature to openFATE so the community can comment here as well. -- openSUSE Feature: https://features.opensuse.org/305886

1 0

[openFATE 305884] Support for creating partitions on ISW arrays
by fate_noreply＠suse.de 29 May '09

29 May '09

Feature changed by: Michael Löffler (michl19) Feature #305884, revision 10 Title: Support for creating partitions on ISW arrays - openSUSE-11.2: Rejected by Stephan Kulow (coolo) - reject date: 2009-05-20 13:19:33 - reject reason: out of focus for 11.2 + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Marc Ruehrschneck (macrue) - Partner organization: Intel + Partner organization: openSUSE.org Description: Boot and install support for partitioned devices for MD external format (ISW) for supported raid levels (0, 1, 10, 5, 6?). Enable yast-storage to create partitions on ISW arrays. Either enable yast-storage to understand mdp devices (partitionable md devices), or use kpartx to expose the individual array partitions Business case (Partner benefit): - Intel: Enable feature parity with the Windows IMSM stack for Linux - customers + openSUSE.org: Enable feature parity with the Windows IMSM stack for + Linux customers Discussion: #3: Michael Löffler (michl19) (2009-05-27 18:57:38) (reply to #2) I wonder here as well. If not in openSUSE where is the place for upstream devlopment. And I wonder if we can open up the feature to openFATE so the community can comment here as well. -- openSUSE Feature: https://features.opensuse.org/305884

1 0

[openFATE 305584] Do not assume fixed and contiguous device numbers in installation and management tools for storage
by fate_noreply＠suse.de 29 May '09

29 May '09

Feature changed by: Tejun Heo (teheo) Feature #305584, revision 12 Title: Do not assume fixed and contiguous device numbers in installation and management tools for storage openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Matthias Eckermann (mge1512) Requested by: Tejun Heo (teheo) Description: Subject: [Research] head up on upcoming extended block devt change From: Tejun Heo <tj(a)kernel.org> Date: Thu, 18 Dec 2008 12:59:21 +0900 Reply-To: research(a)suse.de Hello, all. From soon to be released 2.6.28, the kernel contains extended block devt support, which basically allocates block device numbers dynamically from major number 259 (might expand to other major numbers if ever necessary). This means that device numbers belonging to the same device become non-contiguous and can be on different major numbers. This will remove the 15 partition limit on /dev/sdX's and increase the total number of supported SCSI disks considerably. Also, it's used by md to allow partitioning of /dev/mdX's thus removing the distinction of partitionable and non-partitionable md devices. For example, /dev/sda with 60 partitions can look like as follows. # cat /proc/partitions major minor #blocks name 8 0 156290904 sda 8 1 8001 sda1 8 2 8032 sda2 8 3 8032 sda3 8 4 1 sda4 ... 8 15 8001 sda15 259 0 8001 sda16 259 1 8001 sda17 259 2 8001 sda18 ... 259 43 8001 sda59 259 44 8001 sda60 For detailed overview, please take a look at the following message. http://article.gmane.org/gmane.linux.kernel/701825 As device node creation is completely dynamic these days, installed systems usually can cope fine with this change; however, in installation and management tools, there seem to be many places which assume fixed and contiguous device numbers. To ease hunting down those areas, a debug option is available which forces every block device to be allocated on the dynamic major non-consecutively. With the debug option turned on, the above disk will look like the following. # cat /proc/partitions major minor #blocks name 8 0 156290904 sda 259 262144 8001 sda1 259 786432 8032 sda2 259 131072 8032 sda3 259 655360 1 sda4 259 393216 8001 sda5 259 917504 8001 sda6 259 65536 8001 sda7 ... 259 114688 8001 sda55 259 638976 8001 sda56 259 376832 8001 sda57 259 901120 8001 sda58 259 245760 8001 sda59 259 770048 8001 sda60 So, the installation / management tools need to follow /sys/block/*/device/driver to determine which type of device it is and use /sys/block/*/dev to determine its device number. I'll add a kernel parameter (say, block.force_ext_devt) so that this debug option can be turned on and off during boot so that people who don't work on related subsystems don't have to suffer. I'm not sure how and when to proceed with this yet but I definitely think we'll need plenty of time to sort this out completely. Any ideas on how to proceed on this? Thanks. -- tejun Discussion: #1: Tejun Heo (teheo) (2008-12-22 13:31:11) So... when and how do we proceed with things like this? I wanna enable it in HEAD but SLES11 hasn't branched out from HEAD yet but I don't think we should wait till SLES11 is released. #2: Matthias Eckermann (mge1512) (2008-12-22 10:24:58) (reply to #1) SLE 11 has precedence over anything else we currently do - with respect to focus and time spent on it. Thus we should concentrate on SLE 11 and wait with those changes after release of SLE 11. There are more than enough P1 and P2 issues with the SLE 11 kernel to work on, ... Vojtech? #3: Vojtech Pavlik (vojtech_pavlik) (2008-12-22 12:14:19) I agree, Matthias, and I see no reason why this couldn't wait until SLES11 branches out of HEAD. #4: Tejun Heo (teheo) (2008-12-23 11:52:19) Alright, then. I'll enable it when SLES11 branches out. Thanks. + #5: Tejun Heo (teheo) (2009-05-29 16:55:23) + Added genhd.mangle_devt parameter and enabled DEBUG_BLOCK_EXT_DEVT for + all configs except for vanilla's and ppc/ps3. Ext major and mangled + minor can be enabled by specifying "genhd.mangle_devt=1" as kernel + parameter. Have fun. :-) -- openSUSE Feature: https://features.opensuse.org/305584

1 0

[openFATE 305588] kdump support for autoyast installation
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305588, revision 13 Title: kdump support for autoyast installation - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important Requested by: Stefan Fent (sfent) Description: In SLES11 it is possible to add an autoyast section for kdump to the autoyast.xml file. This does not work in openSUSE11.1. Please add support for this in openSUSE as well. See bug #456707 for reference. Discussion: #2: Jozef Uhliarik (juhliarik) (2009-05-18 16:54:53) added kdump support for autoyast installation to trunk. changes only for control file in installation. the feature will be available with package yast2-installation 2.18.15. IMHO it is done #3: Jozef Uhliarik (juhliarik) (2009-05-28 17:26:47) yast2-installation 2.18.15 is submitted. The feature is done. -- openSUSE Feature: https://features.opensuse.org/305588

1 0

[openFATE 305588] kdump support for autoyast installation
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305588, revision 12 Title: kdump support for autoyast installation openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Stefan Fent (sfent) Description: In SLES11 it is possible to add an autoyast section for kdump to the autoyast.xml file. This does not work in openSUSE11.1. Please add support for this in openSUSE as well. See bug #456707 for reference. Discussion: #2: Jozef Uhliarik (juhliarik) (2009-05-18 16:54:53) added kdump support for autoyast installation to trunk. changes only for control file in installation. the feature will be available with package yast2-installation 2.18.15. IMHO it is done + #3: Jozef Uhliarik (juhliarik) (2009-05-28 17:26:47) + yast2-installation 2.18.15 is submitted. The feature is done. -- openSUSE Feature: https://features.opensuse.org/305588

1 0

[openFATE 305443] Support of Bluetooth Mouse and Keyboard on installation
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305443, revision 9 Title: Support of Bluetooth Mouse and Keyboard on installation openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-05-28 15:38:59 reject reason: Out of resources for 11.2. Priority Requester: Desirable - openSUSE-11.3: New - Priority - Requester: Desirable Requested by: Vladimir Botka (vbotka) Description: On Installation the user should be able to decide to use the bluetooth mouse/keyboard. Maybe just in the case that no other mouse/keyboard is detected. Relations: - Bluetooth mouse not detected (novell/bugzilla/id: 445583) https://bugzilla.novell.com/show_bug.cgi?id=445583 Discussion: #2: Vladimir Botka (vbotka) (2009-05-28 17:01:06)  I suggest to throw away this feature request completely. Here are the reasons. Blueooth (BT) keyboard/mouse sets are equipped with proprietary usb bluetooth dongles and works as a standard usb keyboard/mouse from the computer point of view. After the startup the usb dongle is running in the " Human interface device" (HID) mode. This behaviour enables to use the BT keyboard/mouse with BIOS only. Then, when the system is booted and the bluetooth subsystem is operational the usb dongle can be switched to to the "Host Controller Interface" (HCI) mode. Then the usb dongle operates as a BT controller and the keyboard/mouse are connected to the system as BT devices. The utility hid2hci should cover the whole transfer, but it works only for a couple of devices (which I have heard of, I have seen none). Generally I have seen either the BT keyboard/mouse is used in the HID mode with the proprietary usb dongle or the BT keyboard/mouse is used as a BT devices secondary input connected to the bt HCI controller (typically notebook). The only situation for which this feature really make sens is the BT mouse and the notebook. There is no HID mode during the installation. - + #3: Christoph Thiel (cthiel1) (2009-05-28 17:07:49) (reply to #2) + Agreed. -- openSUSE Feature: https://features.opensuse.org/305443

1 0

[openFATE 305443] Support of Bluetooth Mouse and Keyboard on installation
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature changed by: Vladimir Botka (vbotka) Feature #305443, revision 8 Title: Support of Bluetooth Mouse and Keyboard on installation openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-05-28 15:38:59 reject reason: Out of resources for 11.2. Priority Requester: Desirable openSUSE-11.3: New Priority Requester: Desirable Requested by: Vladimir Botka (vbotka) Description: On Installation the user should be able to decide to use the bluetooth mouse/keyboard. Maybe just in the case that no other mouse/keyboard is detected. Relations: - Bluetooth mouse not detected (novell/bugzilla/id: 445583) https://bugzilla.novell.com/show_bug.cgi?id=445583 + Discussion: + #2: Vladimir Botka (vbotka) (2009-05-28 17:01:06) +  + I suggest to throw away this feature request completely. Here are the + reasons. + Blueooth (BT) keyboard/mouse sets are equipped with proprietary usb + bluetooth dongles and works as a standard usb keyboard/mouse from the + computer point of view. After the startup the usb dongle is running in + the " Human interface device" (HID) mode. This behaviour enables to use + the BT keyboard/mouse with BIOS only. Then, when the system is booted + and the bluetooth subsystem is operational the usb dongle can be + switched to to the "Host Controller Interface" (HCI) mode. Then the usb + dongle operates as a BT controller and the keyboard/mouse are connected + to the system as BT devices. The utility hid2hci should cover the whole + transfer, but it works only for a couple of devices (which I have heard + of, I have seen none). Generally I have seen either the BT + keyboard/mouse is used in the HID mode with the proprietary usb dongle + or the BT keyboard/mouse is used as a BT devices secondary input + connected to the bt HCI controller (typically notebook). + The only situation for which this feature really make sens is the BT + mouse and the notebook. There is no HID mode during the installation. + -- openSUSE Feature: https://features.opensuse.org/305443

1 0