Activity log for bug #1775195

Date Who What changed Old value New value Message
2018-06-05 14:43:01 Eric Desrochers bug added bug
2018-06-05 14:43:16 Eric Desrochers bug added subscriber Adam Stokes
2018-06-05 14:43:32 Eric Desrochers bug added subscriber Louis Bouchard
2018-06-05 14:43:49 Eric Desrochers tags sts
2018-06-05 14:43:55 Eric Desrochers sosreport (Ubuntu): importance Undecided Wishlist
2018-06-05 14:45:50 Bryan Quigley bug added subscriber Bryan Quigley
2018-06-05 14:47:16 Eric Desrochers bug added subscriber Dan Streetman
2018-06-05 14:50:11 Eric Desrochers nominated for series Ubuntu Trusty
2018-06-05 14:50:11 Eric Desrochers bug task added sosreport (Ubuntu Trusty)
2018-06-05 14:50:11 Eric Desrochers nominated for series Ubuntu Xenial
2018-06-05 14:50:11 Eric Desrochers bug task added sosreport (Ubuntu Xenial)
2018-06-05 14:50:11 Eric Desrochers nominated for series Ubuntu Cosmic
2018-06-05 14:50:11 Eric Desrochers bug task added sosreport (Ubuntu Cosmic)
2018-06-05 14:50:11 Eric Desrochers nominated for series Ubuntu Bionic
2018-06-05 14:50:11 Eric Desrochers bug task added sosreport (Ubuntu Bionic)
2018-06-05 14:50:18 Eric Desrochers sosreport (Ubuntu Bionic): importance Undecided Wishlist
2018-06-05 14:50:20 Eric Desrochers sosreport (Ubuntu Xenial): importance Undecided Wishlist
2018-06-05 14:50:22 Eric Desrochers sosreport (Ubuntu Trusty): importance Undecided Wishlist
2018-06-05 14:50:31 Eric Desrochers sosreport (Ubuntu Cosmic): importance Wishlist Medium
2018-06-05 14:51:44 Eric Desrochers bug watch added https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818
2018-06-05 14:51:44 Eric Desrochers bug task added sosreport (Debian)
2018-06-05 14:53:34 Eric Desrochers description As we speak, sosreport released an interim version of sosreport (3.5.1) 7 days ago, but 3.6 will be release in late June 2018 with further enhancements in core sosreport functionality. I already did the request for debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 It would be great to have sosreport v3.6 in Cosmic & SRU'd in all supported stable release once official release upstream. Just like we did for v3.5. Considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. As we speak, sosreport released an interim version of sosreport (3.5.1) 7 days ago, but 3.6 will be release in late June 2018 with further enhancements in core sosreport functionality. I already did the request for debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 It would be great to have sosreport v3.6 in Cosmic & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5,
2018-06-05 16:11:44 Bug Watch Updater sosreport (Debian): status Unknown New
2018-06-14 14:14:23 Eric Desrochers sosreport (Ubuntu Cosmic): assignee Eric Desrochers (slashd)
2018-06-14 14:16:48 Eric Desrochers sosreport (Ubuntu Cosmic): status New In Progress
2018-10-03 22:19:53 Eric Desrochers description As we speak, sosreport released an interim version of sosreport (3.5.1) 7 days ago, but 3.6 will be release in late June 2018 with further enhancements in core sosreport functionality. I already did the request for debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 It would be great to have sosreport v3.6 in Cosmic & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5, As we speak, sosreport released an interim version of sosreport (3.5.1) 7 days ago, but 3.6 will be release in late June 2018 with further enhancements in core sosreport functionality. I already did the request for debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 It would be great to have sosreport v3.6 in Cosmic & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-10-12 20:07:55 Eric Desrochers sosreport (Ubuntu Cosmic): assignee Eric Desrochers (slashd) Louis Bouchard (louis)
2018-11-05 15:16:16 Eric Desrochers sosreport (Ubuntu): assignee Louis Bouchard (louis) Eric Desrochers (slashd)
2018-11-05 15:16:20 Eric Desrochers sosreport (Ubuntu Cosmic): assignee Louis Bouchard (louis)
2018-11-05 15:48:33 Eric Desrochers description As we speak, sosreport released an interim version of sosreport (3.5.1) 7 days ago, but 3.6 will be release in late June 2018 with further enhancements in core sosreport functionality. I already did the request for debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 It would be great to have sosreport v3.6 in Cosmic & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-05 15:48:35 Eric Desrochers summary sosreport v3.6 [sync] sosreport v3.6
2018-11-05 15:49:55 Eric Desrochers sosreport (Ubuntu Cosmic): status In Progress New
2018-11-05 15:49:59 Eric Desrochers sosreport (Ubuntu Cosmic): importance Medium Wishlist
2018-11-05 18:33:46 Eric Desrochers sosreport (Ubuntu): status In Progress Fix Released
2018-11-05 20:06:23 Eric Desrochers sosreport (Ubuntu Cosmic): status New In Progress
2018-11-05 20:06:25 Eric Desrochers sosreport (Ubuntu Cosmic): assignee Eric Desrochers (slashd)
2018-11-05 20:09:13 Eric Desrochers summary [sync] sosreport v3.6 [sync][sru]sosreport v3.6
2018-11-07 18:05:24 Bug Watch Updater sosreport (Debian): status New Fix Released
2018-11-09 18:37:53 Eric Desrochers description sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes ## SRU JUSTIFICATION ## ## DRAFT ## [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [Test Case] * Install sosreport * Run sosreport [Regression Potential] * Regression risk is low, as long as the core functionnality works (Package manager, ...) * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible. Plugin bug is an eventuality, but they are usually easy to fix and the impact wil be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-09 18:40:44 Eric Desrochers description ## SRU JUSTIFICATION ## ## DRAFT ## [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [Test Case] * Install sosreport * Run sosreport [Regression Potential] * Regression risk is low, as long as the core functionnality works (Package manager, ...) * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible. Plugin bug is an eventuality, but they are usually easy to fix and the impact wil be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes ## SRU JUSTIFICATION ## ## DRAFT ## [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [Test Case]  * Install sosreport  * Run sosreport [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible. Plugin bug is an eventuality, but they are usually easy to fix and the impact wil be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-09 18:42:19 Eric Desrochers description ## SRU JUSTIFICATION ## ## DRAFT ## [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [Test Case]  * Install sosreport  * Run sosreport [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible. Plugin bug is an eventuality, but they are usually easy to fix and the impact wil be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes ## SRU JUSTIFICATION ## ## DRAFT ## [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [Test Case]  * Install sosreport  * Run sosreport [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...) * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible. Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-09 18:46:02 Eric Desrochers description ## SRU JUSTIFICATION ## ## DRAFT ## [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [Test Case]  * Install sosreport  * Run sosreport [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...) * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible. Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes ## SRU JUSTIFICATION ## ## DRAFT ## [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [Test Case]  * Install sosreport  * Run sosreport [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible. Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-09 18:47:48 Eric Desrochers description ## SRU JUSTIFICATION ## ## DRAFT ## [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [Test Case]  * Install sosreport  * Run sosreport [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible. Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes ## SRU JUSTIFICATION ## ## DRAFT ## [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible. Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-09 18:56:48 Eric Desrochers sosreport (Ubuntu Bionic): assignee Eric Desrochers (slashd)
2018-11-09 19:54:21 Eric Desrochers sosreport (Ubuntu Xenial): assignee Eric Desrochers (slashd)
2018-11-09 19:54:23 Eric Desrochers sosreport (Ubuntu Trusty): assignee Eric Desrochers (slashd)
2018-11-09 19:54:28 Eric Desrochers sosreport (Ubuntu Bionic): status New In Progress
2018-11-09 19:54:30 Eric Desrochers sosreport (Ubuntu Xenial): status New In Progress
2018-11-09 19:54:33 Eric Desrochers sosreport (Ubuntu Trusty): status New In Progress
2018-11-09 19:57:30 Eric Desrochers description ## SRU JUSTIFICATION ## ## DRAFT ## [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible. Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible. Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-09 20:01:24 Eric Desrochers description [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible. Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-09 21:14:36 Eric Desrochers description [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Bugs identified during our testing] * juju plugin detection doesn't work if installed as a snap: https://github.com/sosreport/sos/issues/1475 (fix already submitted upstream) [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-09 21:22:03 Eric Desrochers description [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Bugs identified during our testing] * juju plugin detection doesn't work if installed as a snap: https://github.com/sosreport/sos/issues/1475 (fix already submitted upstream) [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Bugs identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475 (fix already submitted upstream) [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-09 21:53:16 Chris Newcomer bug watch added https://github.com/sosreport/sos/issues/1475
2018-11-12 14:30:11 Eric Desrochers description [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Bugs identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475 (fix already submitted upstream) [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Issues identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply juju in sosreport have always been made for .deb so far. It's not a regression introduce in 3.6, and IMHO not a blocker for the current SRU. It could be patch later on when the upstream discussion/approval will be done. [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-12 15:19:15 Eric Desrochers description [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). Now, it would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Issues identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply juju in sosreport have always been made for .deb so far. It's not a regression introduce in 3.6, and IMHO not a blocker for the current SRU. It could be patch later on when the upstream discussion/approval will be done. [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done. [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-12 15:41:07 Eric Desrochers description [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done. [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport (sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and sosreport has the capability to detect (based on file and package) if it exist and/or installed and then run the necessary plugins accordingly) [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done. [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-12 15:44:24 Eric Desrochers description [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport (sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and sosreport has the capability to detect (based on file and package) if it exist and/or installed and then run the necessary plugins accordingly) [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done. [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done. [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-12 15:45:37 Eric Desrochers description [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done. [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: [https://www.ubuntu.com/about/release-cycle] Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport    - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done. [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-13 17:49:14 Brian Murray sosreport (Ubuntu Cosmic): status In Progress Incomplete
2018-11-13 19:43:31 Eric Desrochers description [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: [https://www.ubuntu.com/about/release-cycle] Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport    - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done. [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: [https://www.ubuntu.com/about/release-cycle] Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport    - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done. * https://bugs.launchpad.net/ubuntu/trusty/+source/sosreport/+bug/1775195/comments/6 [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-13 19:44:50 Eric Desrochers description [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: [https://www.ubuntu.com/about/release-cycle] Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport    - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done. * https://bugs.launchpad.net/ubuntu/trusty/+source/sosreport/+bug/1775195/comments/6 [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: [https://www.ubuntu.com/about/release-cycle] Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport    - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done.  * Landscape doesn't substitute sensible information (password, ...) https://bugs.launchpad.net/ubuntu/trusty/+source/sosreport/+bug/1775195/comments/6 [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-13 20:16:34 Eric Desrochers description [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: [https://www.ubuntu.com/about/release-cycle] Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport    - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done.  * Landscape doesn't substitute sensible information (password, ...) https://bugs.launchpad.net/ubuntu/trusty/+source/sosreport/+bug/1775195/comments/6 [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: [https://www.ubuntu.com/about/release-cycle] Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport    - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done.  * Landscape plugin doesn't substitute sensible information such as password. Fix : https://github.com/sosreport/sos/commit/b96bdab03f06408e162b1733b20e8ba9fbf8e012 [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-13 20:17:06 Eric Desrochers description [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: [https://www.ubuntu.com/about/release-cycle] Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport    - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done.  * Landscape plugin doesn't substitute sensible information such as password. Fix : https://github.com/sosreport/sos/commit/b96bdab03f06408e162b1733b20e8ba9fbf8e012 [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: [https://www.ubuntu.com/about/release-cycle] Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport    - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done.  * Landscape plugin (and possibly other plugins) doesn't substitute sensible information such as password. Fix : https://github.com/sosreport/sos/commit/b96bdab03f06408e162b1733b20e8ba9fbf8e012 [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-13 20:44:54 Eric Desrochers description [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: [https://www.ubuntu.com/about/release-cycle] Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport    - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done.  * Landscape plugin (and possibly other plugins) doesn't substitute sensible information such as password. Fix : https://github.com/sosreport/sos/commit/b96bdab03f06408e162b1733b20e8ba9fbf8e012 [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: [https://www.ubuntu.com/about/release-cycle] Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case]  * Install sosreport  * Run sosreport    - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing]  * juju plugin detection doesn't work if installed as a snap:    https://github.com/sosreport/sos/issues/1475    Fix already submitted upstream. This is not a new thing, we simply    juju in sosreport have always been made for .deb so far. It's not a    regression introduce in 3.6, and IMHO not a blocker for the current    SRU. It could be patch later on when the upstream discussion/approval    will be done.  * Certain plugins may or may not substitute sensible information such as password. Upstream fix : https://github.com/sosreport/sos/commit/b96bdab03f06408e162b1733b20e8ba9fbf8e012 [Regression Potential]  * Regression risk is low, as long as the core functionnality works (Package manager, ...)  * autopkgtest reveal no regressions.  * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and bug fixes, including: 29 new plugins: alternatives, ansible, btrfs, buildah, clear_containers, date, elastic, fibrechannel, host, kata_containers, lustre, memcached, mssql, networkmanager, nvme, omnipath_client, omnipath_manager, opendaylight, openstack_octavia, ovirt_provider_ovn, ovn_central, ovn_host, rear, release, runc, skydive, unpackaged, watchdog, wireless User and policy defined command line presets The ability to save and recall specific combinations of command line parameters Policy authors may define presets for specific situations, products or other uses (e.g. "cantboot", "rhel", "openshift" etc.). Size limits for external commands Certain commands produce large volumes of data, inflating report size (e.g. journalctl): the command collection interface now allows an arbitrary size limit to be applied, which includes memory used during the run (reducing sosreport's peak memory usage). Automatic file and command size limits Plugins that do not specify an explicit size limit for files or commands are now subject to the default value (specified with the --log-size command line option). Plugin authors may override this behaviour if needed Concurrent plugin execution Plugins are now run in parallel using a thread pool Reduces runtime by up to 50% (workload dependent) Command line --threads option to set the number of threads to use, or to disable parallel execution New profiles (including containers and the Apache webserver) major enhancements to core features and existing plugins: better package manager version information policy support for detecting package managed files fixed exit status propagation deprecated optparse replaced with argparse simplified and improved SoSOptions interface better error handling during interactive prompting allow journal collection by identifier allow collection of journal message catalogs support for collecting binary file data more fine-grained system plugins (date etc.) policy defined report file name patterns more human-readable report file names by default increased default log size (25MiB vs. 10MiB) support for forbidden path lists and forbid logging support for enabling plugins by kernel module name support for enabling plugins by executable name support for collecting eBPF (bpftool) data support for device information via add_udev_info() support for detecting and reporting unpackaged binaries optional collection of the RPMDB improved archive compression level and multithreading default log size increased from 10MiB to 25MiB improved debug logging and ENOSPC handling major updates to the IPA plugin major updates to the Docker plugin string decoding fixes DNF and Yum module support OpenShift 3.10 support Python3 fixes
2018-11-13 21:05:27 Eric Desrochers sosreport (Ubuntu Cosmic): status Incomplete In Progress