| 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 |
|
| 2018-11-14 15:19:15 |
David Coronel |
bug |
|
|
added subscriber David Coronel |
| 2018-11-14 18:45:25 |
Eric Desrochers |
sosreport (Ubuntu Trusty): status |
In Progress |
Won't Fix |
|
| 2018-11-14 21:01:03 |
Brian Murray |
sosreport (Ubuntu Cosmic): status |
In Progress |
Fix Committed |
|
| 2018-11-14 21:01:05 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-11-14 21:01:09 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2018-11-14 21:01:15 |
Brian Murray |
tags |
sts |
sts verification-needed verification-needed-cosmic |
|
| 2018-11-14 21:05:17 |
Brian Murray |
sosreport (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2018-11-14 21:05:26 |
Brian Murray |
tags |
sts verification-needed verification-needed-cosmic |
sts verification-needed verification-needed-bionic verification-needed-cosmic |
|
| 2018-11-14 21:09:06 |
Brian Murray |
sosreport (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2018-11-14 21:09:15 |
Brian Murray |
tags |
sts verification-needed verification-needed-bionic verification-needed-cosmic |
sts verification-needed verification-needed-bionic verification-needed-cosmic verification-needed-xenial |
|
| 2018-11-15 19:35:02 |
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.
* 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 |
[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]
* [minor] 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, 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.
* [major] Certain plugins may or may not substitute sensible information such as password. Upstream fix found and applied : 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-16 16:54:32 |
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]
* [minor] 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, 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.
* [major] Certain plugins may or may not substitute sensible information such as password. Upstream fix found and applied : 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]
* [minor] 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, 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.
* [major] Certain plugins may or may not substitute sensible
information such as password. Upstream fix found and applied : https://github.com/sosreport/sos/commit/b96bdab03f06408e162b1733b20e8ba9fbf8e012
* [minor] kernel plugin dont collect some tracing instance files
https://github.com/sosreport/sos/commit/d6379b5ba0f381ea8ec2403b9985100a946a5866
Ubuntu Bug #1803735
[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-16 19:21:14 |
Eric Desrochers |
tags |
sts verification-needed verification-needed-bionic verification-needed-cosmic verification-needed-xenial |
sos36 sts verification-needed verification-needed-bionic verification-needed-cosmic verification-needed-xenial |
|
| 2018-11-22 02:29:17 |
Eric Desrochers |
tags |
sos36 sts verification-needed verification-needed-bionic verification-needed-cosmic verification-needed-xenial |
sos36 sts verification-done-bionic verification-done-cosmic verification-done-xenial verification-needed |
|
| 2018-11-22 02:36:49 |
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]
* [minor] 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, 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.
* [major] Certain plugins may or may not substitute sensible
information such as password. Upstream fix found and applied : https://github.com/sosreport/sos/commit/b96bdab03f06408e162b1733b20e8ba9fbf8e012
* [minor] kernel plugin dont collect some tracing instance files
https://github.com/sosreport/sos/commit/d6379b5ba0f381ea8ec2403b9985100a946a5866
Ubuntu Bug #1803735
[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]
* [minor] 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, 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.
* [major] Certain plugins may or may not substitute sensible
information such as password. Upstream fix found and applied : https://github.com/sosreport/sos/commit/b96bdab03f06408e162b1733b20e8ba9fbf8e012
d/p/fix-string-substitution-method.patch
* [minor] kernel plugin dont collect some tracing instance files
https://github.com/sosreport/sos/commit/d6379b5ba0f381ea8ec2403b9985100a946a5866
Ubuntu Bug #1803735
d/p/dont-collect-some-tracing-instance-files.patch
[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-22 02:37: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).
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]
* [minor] 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, 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.
* [major] Certain plugins may or may not substitute sensible
information such as password. Upstream fix found and applied : https://github.com/sosreport/sos/commit/b96bdab03f06408e162b1733b20e8ba9fbf8e012
d/p/fix-string-substitution-method.patch
* [minor] kernel plugin dont collect some tracing instance files
https://github.com/sosreport/sos/commit/d6379b5ba0f381ea8ec2403b9985100a946a5866
Ubuntu Bug #1803735
d/p/dont-collect-some-tracing-instance-files.patch
[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]
* [minor] 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, 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.
* [major] Certain plugins may or may not substitute sensible
information such as password. Upstream fix found and applied :
https://github.com/sosreport/sos/commit/b96bdab
- d/p/fix-string-substitution-method.patch
* [minor] kernel plugin dont collect some tracing instance files
https://github.com/sosreport/sos/commit/d6379b5
Ubuntu Bug #1803735
- d/p/dont-collect-some-tracing-instance-files.patch
[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-22 02:38:14 |
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]
* [minor] 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, 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.
* [major] Certain plugins may or may not substitute sensible
information such as password. Upstream fix found and applied :
https://github.com/sosreport/sos/commit/b96bdab
- d/p/fix-string-substitution-method.patch
* [minor] kernel plugin dont collect some tracing instance files
https://github.com/sosreport/sos/commit/d6379b5
Ubuntu Bug #1803735
- d/p/dont-collect-some-tracing-instance-files.patch
[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]
* [minor] 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, 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.
* [major] Certain plugins may or may not substitute sensible
information such as password. Upstream fix found and applied :
https://github.com/sosreport/sos/commit/b96bdab
- d/p/fix-string-substitution-method.patch
* [minor] kernel plugin dont collect some tracing instance files
https://github.com/sosreport/sos/commit/d6379b5
LP: #1803735
- d/p/dont-collect-some-tracing-instance-files.patch
[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-22 02:41:00 |
Eric Desrochers |
summary |
[sync][sru]sosreport v3.6 |
[sync][sru] Backport of sosreport v3.6 |
|
| 2018-11-26 16:20:20 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-11-26 16:20:41 |
Launchpad Janitor |
sosreport (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-11-26 16:20:52 |
Launchpad Janitor |
sosreport (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2018-11-26 16:30:28 |
Launchpad Janitor |
sosreport (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2018-12-18 18:51:04 |
Bryan Quigley |
sosreport (Ubuntu Trusty): status |
Won't Fix |
New |
|
| 2018-12-18 21:14:31 |
Eric Desrochers |
sosreport (Ubuntu Trusty): status |
New |
In Progress |
|
| 2019-05-13 17:25:44 |
Eric Desrochers |
sosreport (Ubuntu Trusty): status |
In Progress |
Won't Fix |
|
