| 2022-02-16 03:58:19 |
nikhil kshirsagar |
bug |
|
|
added bug |
| 2022-02-16 04:00:59 |
nikhil kshirsagar |
nominated for series |
|
Ubuntu Bionic |
|
| 2022-02-16 04:00:59 |
nikhil kshirsagar |
bug task added |
|
sosreport (Ubuntu Bionic) |
|
| 2022-02-16 04:00:59 |
nikhil kshirsagar |
nominated for series |
|
Ubuntu Focal |
|
| 2022-02-16 04:00:59 |
nikhil kshirsagar |
bug task added |
|
sosreport (Ubuntu Focal) |
|
| 2022-02-16 04:00:59 |
nikhil kshirsagar |
nominated for series |
|
Ubuntu Jammy |
|
| 2022-02-16 04:00:59 |
nikhil kshirsagar |
bug task added |
|
sosreport (Ubuntu Jammy) |
|
| 2022-02-16 04:00:59 |
nikhil kshirsagar |
nominated for series |
|
Ubuntu Impish |
|
| 2022-02-16 04:00:59 |
nikhil kshirsagar |
bug task added |
|
sosreport (Ubuntu Impish) |
|
| 2022-02-16 04:21:32 |
Eric Desrochers |
sosreport (Ubuntu Jammy): assignee |
|
Eric Desrochers (slashd) |
|
| 2022-02-16 04:21:38 |
Eric Desrochers |
sosreport (Ubuntu Jammy): importance |
Undecided |
Medium |
|
| 2022-02-16 04:21:41 |
Eric Desrochers |
sosreport (Ubuntu Jammy): status |
New |
In Progress |
|
| 2022-02-16 04:23:14 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2022-02-16 04:23:38 |
Eric Desrochers |
bug |
|
|
added subscriber Arif Ali |
| 2022-02-16 04:23:51 |
Eric Desrochers |
tags |
|
seg sts |
|
| 2022-02-16 04:30:09 |
Eric Desrochers |
bug watch added |
|
https://github.com/sosreport/sos/issues/2860 |
|
| 2022-02-16 05:08:29 |
Eric Desrochers |
sosreport (Ubuntu Impish): assignee |
|
nikhil kshirsagar (nkshirsagar) |
|
| 2022-02-16 05:08:35 |
Eric Desrochers |
sosreport (Ubuntu Focal): assignee |
|
nikhil kshirsagar (nkshirsagar) |
|
| 2022-02-16 05:08:41 |
Eric Desrochers |
sosreport (Ubuntu Bionic): assignee |
|
nikhil kshirsagar (nkshirsagar) |
|
| 2022-02-16 05:09:40 |
Eric Desrochers |
sosreport (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2022-02-16 05:09:42 |
Eric Desrochers |
sosreport (Ubuntu Focal): importance |
Undecided |
Medium |
|
| 2022-02-16 05:09:45 |
Eric Desrochers |
sosreport (Ubuntu Impish): importance |
Undecided |
Medium |
|
| 2022-02-16 11:44:54 |
Launchpad Janitor |
sosreport (Ubuntu Jammy): status |
In Progress |
Fix Released |
|
| 2022-02-16 19:24:25 |
Eric Desrochers |
bug |
|
|
added subscriber Edward Hope-Morley |
| 2022-02-16 19:27:32 |
Eric Desrochers |
description |
[IMPACT]
The sos team is pleased to announce the release of sos-4.3. This release includes a number of quality-of-life changes to both end user experience and for contributors dealing with the plugin API.
[TEST PLAN]
Documentation for Special Cases:
https://wiki.ubuntu.com/SosreportUpdates
[WHERE PROBLEM COULD OCCUR]
Regression could occur at core functionality, which may prevent sos (or its subcommand to work. I consider this regression type as 'low'. That is generally well tested, and we would find a problem at an early stage during the verification phase if it is the case.
On the other end, regression could happen and are some kind of expected at plugins levels. As of today, sos has more than 300 plugins. It is nearly impossible to test them all.
If a regression is found in a plugin, it is rarely affecting sos core functionalities nor other plugins. So mainly the impact would be limited to that plugin. The impact being that the plugin can't or partially can collect the information that it is instructed to gather.
A 3rd party vendor would then ask user/customer to collect the information manually for that particular plugins.
Plugins are segmented by services and/or applications (e.g. openstack_keystone, bcache, system, logs, ...) in order to collect things accordingly to the plugin detected or intentionally requested for.
Sosreport plugins philosophy is to (as much as possible) maintain backward compatibility when updating a plugin. The risk that an ancient version of a software has been dropped, is unlikely, unless it was intended to be that way for particular reasons. Certain plugin also support the DEB installation way and the snap one (MAAS, LXD, ...) so all Ubuntu standard installation types are covered.
[OTHER INFORMATION]
Release note:
https://github.com/sosreport/sos/releases/tag/4.3 |
[IMPACT]
The sos team is pleased to announce the release of sos-4.3. This release includes a number of quality-of-life changes to both end user experience and for contributors dealing with the plugin API.
[TEST PLAN]
Documentation for Special Cases:
https://wiki.ubuntu.com/SosreportUpdates
[WHERE PROBLEM COULD OCCUR]
Regression could occur at core functionality, which may prevent sos (or its subcommand to work. I consider this regression type as 'low'. That is generally well tested, and we would find a problem at an early stage during the verification phase if it is the case.
On the other end, regression could happen and are some kind of expected at plugins levels. As of today, sos has more than 300 plugins. It is nearly impossible to test them all.
If a regression is found in a plugin, it is rarely affecting sos core functionalities nor other plugins. So mainly the impact would be limited to that plugin. The impact being that the plugin can't or partially can collect the information that it is instructed to gather.
A 3rd party vendor would then ask user/customer to collect the information manually for that particular plugins.
Plugins are segmented by services and/or applications (e.g. openstack_keystone, bcache, system, logs, ...) in order to collect things accordingly to the plugin detected or intentionally requested for.
Sosreport plugins philosophy is to (as much as possible) maintain backward compatibility when updating a plugin. The risk that an ancient version of a software has been dropped, is unlikely, unless it was intended to be that way for particular reasons. Certain plugin also support the DEB installation way and the snap one (MAAS, LXD, ...) so all Ubuntu standard installation types are covered.
* Problem found and fixed during the packaging process:
** sos-help module wasn't part of the build process
** sos-help man page wasn't also not part of the build process nor mention in main sos man page
Bug:
https://github.com/sosreport/sos/issues/2860
PR:
https://github.com/sosreport/sos/pull/2861
[OTHER INFORMATION]
Release note:
https://github.com/sosreport/sos/releases/tag/4.3 |
|
| 2022-02-17 14:29:42 |
Eric Desrochers |
description |
[IMPACT]
The sos team is pleased to announce the release of sos-4.3. This release includes a number of quality-of-life changes to both end user experience and for contributors dealing with the plugin API.
[TEST PLAN]
Documentation for Special Cases:
https://wiki.ubuntu.com/SosreportUpdates
[WHERE PROBLEM COULD OCCUR]
Regression could occur at core functionality, which may prevent sos (or its subcommand to work. I consider this regression type as 'low'. That is generally well tested, and we would find a problem at an early stage during the verification phase if it is the case.
On the other end, regression could happen and are some kind of expected at plugins levels. As of today, sos has more than 300 plugins. It is nearly impossible to test them all.
If a regression is found in a plugin, it is rarely affecting sos core functionalities nor other plugins. So mainly the impact would be limited to that plugin. The impact being that the plugin can't or partially can collect the information that it is instructed to gather.
A 3rd party vendor would then ask user/customer to collect the information manually for that particular plugins.
Plugins are segmented by services and/or applications (e.g. openstack_keystone, bcache, system, logs, ...) in order to collect things accordingly to the plugin detected or intentionally requested for.
Sosreport plugins philosophy is to (as much as possible) maintain backward compatibility when updating a plugin. The risk that an ancient version of a software has been dropped, is unlikely, unless it was intended to be that way for particular reasons. Certain plugin also support the DEB installation way and the snap one (MAAS, LXD, ...) so all Ubuntu standard installation types are covered.
* Problem found and fixed during the packaging process:
** sos-help module wasn't part of the build process
** sos-help man page wasn't also not part of the build process nor mention in main sos man page
Bug:
https://github.com/sosreport/sos/issues/2860
PR:
https://github.com/sosreport/sos/pull/2861
[OTHER INFORMATION]
Release note:
https://github.com/sosreport/sos/releases/tag/4.3 |
[IMPACT]
The sos team is pleased to announce the release of sos-4.3. This release includes a number of quality-of-life changes to both end user experience and for contributors dealing with the plugin API.
[TEST PLAN]
Documentation for Special Cases:
https://wiki.ubuntu.com/SosreportUpdates
[WHERE PROBLEM COULD OCCUR]
Regression could occur at core functionality, which may prevent sos (or its subcommand to work. I consider this regression type as 'low'. That is generally well tested, and we would find a problem at an early stage during the verification phase if it is the case.
On the other end, regression could happen and are some kind of expected at plugins levels. As of today, sos has more than 300 plugins. It is nearly impossible to test them all.
If a regression is found in a plugin, it is rarely affecting sos core functionalities nor other plugins. So mainly the impact would be limited to that plugin. The impact being that the plugin can't or partially can collect the information that it is instructed to gather.
A 3rd party vendor would then ask user/customer to collect the information manually for that particular plugins.
Plugins are segmented by services and/or applications (e.g. openstack_keystone, bcache, system, logs, ...) in order to collect things accordingly to the plugin detected or intentionally requested for.
Sosreport plugins philosophy is to (as much as possible) maintain backward compatibility when updating a plugin. The risk that an ancient version of a software has been dropped, is unlikely, unless it was intended to be that way for particular reasons. Certain plugin also support the DEB installation way and the snap one (MAAS, LXD, ...) so all Ubuntu standard installation types are covered.
* Problem found and fixed during the packaging process:
** sos-help module wasn't part of the build process
** sos-help man page wasn't also not part of the build process nor mention in main sos man page
Bug:
https://github.com/sosreport/sos/issues/2860
Both commits of PR need to be part of 4.3 Ubuntu package:
https://github.com/sosreport/sos/pull/2861
[OTHER INFORMATION]
Release note:
https://github.com/sosreport/sos/releases/tag/4.3 |
|
| 2022-02-18 09:13:49 |
nikhil kshirsagar |
attachment added |
|
debdiff_focal_sos4.3 https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1960996/+attachment/5561799/+files/debdiff_focal_sos4.3 |
|
| 2022-02-18 11:17:48 |
nikhil kshirsagar |
sosreport (Ubuntu Impish): status |
New |
In Progress |
|
| 2022-02-18 11:17:53 |
nikhil kshirsagar |
sosreport (Ubuntu Focal): status |
New |
In Progress |
|
| 2022-02-22 18:27:30 |
Brian Murray |
sosreport (Ubuntu Impish): status |
In Progress |
Fix Committed |
|
| 2022-02-22 18:27:33 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-02-22 18:27:35 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2022-02-22 18:27:39 |
Brian Murray |
tags |
seg sts |
seg sts verification-needed verification-needed-impish |
|
| 2022-02-28 03:55:24 |
nikhil kshirsagar |
sosreport (Ubuntu Bionic): assignee |
nikhil kshirsagar (nkshirsagar) |
|
|
| 2022-02-28 03:56:57 |
nikhil kshirsagar |
sosreport (Ubuntu Bionic): importance |
Medium |
Low |
|
| 2022-02-28 08:24:31 |
Dariusz Gadomski |
bug |
|
|
added subscriber Dariusz Gadomski |
| 2022-02-28 16:28:02 |
nikhil kshirsagar |
sosreport (Ubuntu Bionic): importance |
Low |
Medium |
|
| 2022-02-28 16:28:05 |
nikhil kshirsagar |
sosreport (Ubuntu Bionic): assignee |
|
nikhil kshirsagar (nkshirsagar) |
|
| 2022-02-28 16:28:14 |
nikhil kshirsagar |
sosreport (Ubuntu Bionic): status |
New |
In Progress |
|
| 2022-02-28 16:31:57 |
Łukasz Zemczak |
sosreport (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2022-02-28 16:32:03 |
Łukasz Zemczak |
tags |
seg sts verification-needed verification-needed-impish |
seg sts verification-needed verification-needed-focal verification-needed-impish |
|
| 2022-02-28 16:34:07 |
Łukasz Zemczak |
sosreport (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2022-02-28 16:34:14 |
Łukasz Zemczak |
tags |
seg sts verification-needed verification-needed-focal verification-needed-impish |
seg sts verification-needed verification-needed-bionic verification-needed-focal verification-needed-impish |
|
| 2022-03-02 11:14:12 |
nikhil kshirsagar |
description |
[IMPACT]
The sos team is pleased to announce the release of sos-4.3. This release includes a number of quality-of-life changes to both end user experience and for contributors dealing with the plugin API.
[TEST PLAN]
Documentation for Special Cases:
https://wiki.ubuntu.com/SosreportUpdates
[WHERE PROBLEM COULD OCCUR]
Regression could occur at core functionality, which may prevent sos (or its subcommand to work. I consider this regression type as 'low'. That is generally well tested, and we would find a problem at an early stage during the verification phase if it is the case.
On the other end, regression could happen and are some kind of expected at plugins levels. As of today, sos has more than 300 plugins. It is nearly impossible to test them all.
If a regression is found in a plugin, it is rarely affecting sos core functionalities nor other plugins. So mainly the impact would be limited to that plugin. The impact being that the plugin can't or partially can collect the information that it is instructed to gather.
A 3rd party vendor would then ask user/customer to collect the information manually for that particular plugins.
Plugins are segmented by services and/or applications (e.g. openstack_keystone, bcache, system, logs, ...) in order to collect things accordingly to the plugin detected or intentionally requested for.
Sosreport plugins philosophy is to (as much as possible) maintain backward compatibility when updating a plugin. The risk that an ancient version of a software has been dropped, is unlikely, unless it was intended to be that way for particular reasons. Certain plugin also support the DEB installation way and the snap one (MAAS, LXD, ...) so all Ubuntu standard installation types are covered.
* Problem found and fixed during the packaging process:
** sos-help module wasn't part of the build process
** sos-help man page wasn't also not part of the build process nor mention in main sos man page
Bug:
https://github.com/sosreport/sos/issues/2860
Both commits of PR need to be part of 4.3 Ubuntu package:
https://github.com/sosreport/sos/pull/2861
[OTHER INFORMATION]
Release note:
https://github.com/sosreport/sos/releases/tag/4.3 |
[IMPACT]
The sos team is pleased to announce the release of sos-4.3. This release includes a number of quality-of-life changes to both end user experience and for contributors dealing with the plugin API.
[TEST PLAN]
Documentation for Special Cases:
https://wiki.ubuntu.com/SosreportUpdates
[WHERE PROBLEM COULD OCCUR]
Regression could occur at core functionality, which may prevent sos (or its subcommand to work. I consider this regression type as 'low'. That is generally well tested, and we would find a problem at an early stage during the verification phase if it is the case.
On the other end, regression could happen and are some kind of expected at plugins levels. As of today, sos has more than 300 plugins. It is nearly impossible to test them all.
If a regression is found in a plugin, it is rarely affecting sos core functionalities nor other plugins. So mainly the impact would be limited to that plugin. The impact being that the plugin can't or partially can collect the information that it is instructed to gather.
A 3rd party vendor would then ask user/customer to collect the information manually for that particular plugins.
Plugins are segmented by services and/or applications (e.g. openstack_keystone, bcache, system, logs, ...) in order to collect things accordingly to the plugin detected or intentionally requested for.
Sosreport plugins philosophy is to (as much as possible) maintain backward compatibility when updating a plugin. The risk that an ancient version of a software has been dropped, is unlikely, unless it was intended to be that way for particular reasons. Certain plugin also support the DEB installation way and the snap one (MAAS, LXD, ...) so all Ubuntu standard installation types are covered.
* Problem found and fixed during the packaging process:
** sos-help module wasn't part of the build process
** sos-help man page wasn't also not part of the build process nor mention in main sos man page
Bug:
https://github.com/sosreport/sos/issues/2860
Both commits of PR need to be part of 4.3 Ubuntu package:
https://github.com/sosreport/sos/pull/2861
Known issue:
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1962733
[OTHER INFORMATION]
Release note:
https://github.com/sosreport/sos/releases/tag/4.3 |
|
| 2022-03-02 11:22:59 |
nikhil kshirsagar |
description |
[IMPACT]
The sos team is pleased to announce the release of sos-4.3. This release includes a number of quality-of-life changes to both end user experience and for contributors dealing with the plugin API.
[TEST PLAN]
Documentation for Special Cases:
https://wiki.ubuntu.com/SosreportUpdates
[WHERE PROBLEM COULD OCCUR]
Regression could occur at core functionality, which may prevent sos (or its subcommand to work. I consider this regression type as 'low'. That is generally well tested, and we would find a problem at an early stage during the verification phase if it is the case.
On the other end, regression could happen and are some kind of expected at plugins levels. As of today, sos has more than 300 plugins. It is nearly impossible to test them all.
If a regression is found in a plugin, it is rarely affecting sos core functionalities nor other plugins. So mainly the impact would be limited to that plugin. The impact being that the plugin can't or partially can collect the information that it is instructed to gather.
A 3rd party vendor would then ask user/customer to collect the information manually for that particular plugins.
Plugins are segmented by services and/or applications (e.g. openstack_keystone, bcache, system, logs, ...) in order to collect things accordingly to the plugin detected or intentionally requested for.
Sosreport plugins philosophy is to (as much as possible) maintain backward compatibility when updating a plugin. The risk that an ancient version of a software has been dropped, is unlikely, unless it was intended to be that way for particular reasons. Certain plugin also support the DEB installation way and the snap one (MAAS, LXD, ...) so all Ubuntu standard installation types are covered.
* Problem found and fixed during the packaging process:
** sos-help module wasn't part of the build process
** sos-help man page wasn't also not part of the build process nor mention in main sos man page
Bug:
https://github.com/sosreport/sos/issues/2860
Both commits of PR need to be part of 4.3 Ubuntu package:
https://github.com/sosreport/sos/pull/2861
Known issue:
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1962733
[OTHER INFORMATION]
Release note:
https://github.com/sosreport/sos/releases/tag/4.3 |
[IMPACT]
The sos team is pleased to announce the release of sos-4.3. This release includes a number of quality-of-life changes to both end user experience and for contributors dealing with the plugin API.
[TEST PLAN]
Documentation for Special Cases:
https://wiki.ubuntu.com/SosreportUpdates
[WHERE PROBLEMD COULD OCCUR]
Regression could occur at core functionality, which may prevent sos (or its subcommand to work. I consider this regression type as 'low'. That is generally well tested, and we would find a problem at an early stage during the verification phase if it is the case.
On the other end, regression could happen and are some kind of expected at plugins levels. As of today, sos has more than 300 plugins. It is nearly impossible to test them all.
If a regression is found in a plugin, it is rarely affecting sos core functionalities nor other plugins. So mainly the impact would be limited to that plugin. The impact being that the plugin can't or partially can collect the information that it is instructed to gather.
A 3rd party vendor would then ask user/customer to collect the information manually for that particular plugins.
Plugins are segmented by services and/or applications (e.g. openstack_keystone, bcache, system, logs, ...) in order to collect things accordingly to the plugin detected or intentionally requested for.
Sosreport plugins philosophy is to (as much as possible) maintain backward compatibility when updating a plugin. The risk that an ancient version of a software has been dropped, is unlikely, unless it was intended to be that way for particular reasons. Certain plugin also support the DEB installation way and the snap one (MAAS, LXD, ...) so all Ubuntu standard installation types are covered.
* Problem found and fixed during the packaging process:
** sos-help module wasn't part of the build process
** sos-help man page wasn't also not part of the build process nor mention in main sos man page
Bug:
https://github.com/sosreport/sos/issues/2860
Both commits of PR need to be part of 4.3 Ubuntu package:
https://github.com/sosreport/sos/pull/2861
Known issue:
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1962733
[OTHER INFORMATION]
Release note:
https://github.com/sosreport/sos/releases/tag/4.3 |
|
| 2022-03-02 11:23:09 |
nikhil kshirsagar |
description |
[IMPACT]
The sos team is pleased to announce the release of sos-4.3. This release includes a number of quality-of-life changes to both end user experience and for contributors dealing with the plugin API.
[TEST PLAN]
Documentation for Special Cases:
https://wiki.ubuntu.com/SosreportUpdates
[WHERE PROBLEMD COULD OCCUR]
Regression could occur at core functionality, which may prevent sos (or its subcommand to work. I consider this regression type as 'low'. That is generally well tested, and we would find a problem at an early stage during the verification phase if it is the case.
On the other end, regression could happen and are some kind of expected at plugins levels. As of today, sos has more than 300 plugins. It is nearly impossible to test them all.
If a regression is found in a plugin, it is rarely affecting sos core functionalities nor other plugins. So mainly the impact would be limited to that plugin. The impact being that the plugin can't or partially can collect the information that it is instructed to gather.
A 3rd party vendor would then ask user/customer to collect the information manually for that particular plugins.
Plugins are segmented by services and/or applications (e.g. openstack_keystone, bcache, system, logs, ...) in order to collect things accordingly to the plugin detected or intentionally requested for.
Sosreport plugins philosophy is to (as much as possible) maintain backward compatibility when updating a plugin. The risk that an ancient version of a software has been dropped, is unlikely, unless it was intended to be that way for particular reasons. Certain plugin also support the DEB installation way and the snap one (MAAS, LXD, ...) so all Ubuntu standard installation types are covered.
* Problem found and fixed during the packaging process:
** sos-help module wasn't part of the build process
** sos-help man page wasn't also not part of the build process nor mention in main sos man page
Bug:
https://github.com/sosreport/sos/issues/2860
Both commits of PR need to be part of 4.3 Ubuntu package:
https://github.com/sosreport/sos/pull/2861
Known issue:
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1962733
[OTHER INFORMATION]
Release note:
https://github.com/sosreport/sos/releases/tag/4.3 |
[IMPACT]
The sos team is pleased to announce the release of sos-4.3. This release includes a number of quality-of-life changes to both end user experience and for contributors dealing with the plugin API.
[TEST PLAN]
Documentation for Special Cases:
https://wiki.ubuntu.com/SosreportUpdates
[WHERE PROBLEMS COULD OCCUR]
Regression could occur at core functionality, which may prevent sos (or its subcommand to work. I consider this regression type as 'low'. That is generally well tested, and we would find a problem at an early stage during the verification phase if it is the case.
On the other end, regression could happen and are some kind of expected at plugins levels. As of today, sos has more than 300 plugins. It is nearly impossible to test them all.
If a regression is found in a plugin, it is rarely affecting sos core functionalities nor other plugins. So mainly the impact would be limited to that plugin. The impact being that the plugin can't or partially can collect the information that it is instructed to gather.
A 3rd party vendor would then ask user/customer to collect the information manually for that particular plugins.
Plugins are segmented by services and/or applications (e.g. openstack_keystone, bcache, system, logs, ...) in order to collect things accordingly to the plugin detected or intentionally requested for.
Sosreport plugins philosophy is to (as much as possible) maintain backward compatibility when updating a plugin. The risk that an ancient version of a software has been dropped, is unlikely, unless it was intended to be that way for particular reasons. Certain plugin also support the DEB installation way and the snap one (MAAS, LXD, ...) so all Ubuntu standard installation types are covered.
* Problem found and fixed during the packaging process:
** sos-help module wasn't part of the build process
** sos-help man page wasn't also not part of the build process nor mention in main sos man page
Bug:
https://github.com/sosreport/sos/issues/2860
Both commits of PR need to be part of 4.3 Ubuntu package:
https://github.com/sosreport/sos/pull/2861
Known issue:
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1962733
[OTHER INFORMATION]
Release note:
https://github.com/sosreport/sos/releases/tag/4.3 |
|
| 2022-03-02 12:10:12 |
nikhil kshirsagar |
description |
[IMPACT]
The sos team is pleased to announce the release of sos-4.3. This release includes a number of quality-of-life changes to both end user experience and for contributors dealing with the plugin API.
[TEST PLAN]
Documentation for Special Cases:
https://wiki.ubuntu.com/SosreportUpdates
[WHERE PROBLEMS COULD OCCUR]
Regression could occur at core functionality, which may prevent sos (or its subcommand to work. I consider this regression type as 'low'. That is generally well tested, and we would find a problem at an early stage during the verification phase if it is the case.
On the other end, regression could happen and are some kind of expected at plugins levels. As of today, sos has more than 300 plugins. It is nearly impossible to test them all.
If a regression is found in a plugin, it is rarely affecting sos core functionalities nor other plugins. So mainly the impact would be limited to that plugin. The impact being that the plugin can't or partially can collect the information that it is instructed to gather.
A 3rd party vendor would then ask user/customer to collect the information manually for that particular plugins.
Plugins are segmented by services and/or applications (e.g. openstack_keystone, bcache, system, logs, ...) in order to collect things accordingly to the plugin detected or intentionally requested for.
Sosreport plugins philosophy is to (as much as possible) maintain backward compatibility when updating a plugin. The risk that an ancient version of a software has been dropped, is unlikely, unless it was intended to be that way for particular reasons. Certain plugin also support the DEB installation way and the snap one (MAAS, LXD, ...) so all Ubuntu standard installation types are covered.
* Problem found and fixed during the packaging process:
** sos-help module wasn't part of the build process
** sos-help man page wasn't also not part of the build process nor mention in main sos man page
Bug:
https://github.com/sosreport/sos/issues/2860
Both commits of PR need to be part of 4.3 Ubuntu package:
https://github.com/sosreport/sos/pull/2861
Known issue:
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1962733
[OTHER INFORMATION]
Release note:
https://github.com/sosreport/sos/releases/tag/4.3 |
[IMPACT]
The sos team is pleased to announce the release of sos-4.3. This release includes a number of quality-of-life changes to both end user experience and for contributors dealing with the plugin API.
[TEST PLAN]
Documentation for Special Cases:
https://wiki.ubuntu.com/SosreportUpdates
[WHERE PROBLEMS COULD OCCUR]
* Problem found and fixed during the packaging process:
** sos-help module wasn't part of the build process
** sos-help man page wasn't also not part of the build process nor mention in main sos man page
Bug:
https://github.com/sosreport/sos/issues/2860
Both commits of PR need to be part of 4.3 Ubuntu package:
https://github.com/sosreport/sos/pull/2861
Known issue:
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1962733
[OTHER INFORMATION]
Regression could occur at core functionality, which may prevent sos (or its subcommand to work. I consider this regression type as 'low'. That is generally well tested, and we would find a problem at an early stage during the verification phase if it is the case.
On the other end, regression could happen and are some kind of expected at plugins levels. As of today, sos has more than 300 plugins. It is nearly impossible to test them all.
If a regression is found in a plugin, it is rarely affecting sos core functionalities nor other plugins. So mainly the impact would be limited to that plugin. The impact being that the plugin can't or partially can collect the information that it is instructed to gather.
A 3rd party vendor would then ask user/customer to collect the information manually for that particular plugins.
Plugins are segmented by services and/or applications (e.g. openstack_keystone, bcache, system, logs, ...) in order to collect things accordingly to the plugin detected or intentionally requested for.
Sosreport plugins philosophy is to (as much as possible) maintain backward compatibility when updating a plugin. The risk that an ancient version of a software has been dropped, is unlikely, unless it was intended to be that way for particular reasons. Certain plugin also support the DEB installation way and the snap one (MAAS, LXD, ...) so all Ubuntu standard installation types are covered.
Release note:
https://github.com/sosreport/sos/releases/tag/4.3 |
|
| 2022-03-02 12:13:00 |
nikhil kshirsagar |
bug watch added |
|
https://github.com/sosreport/sos/issues/2873 |
|
| 2022-03-07 10:27:41 |
nikhil kshirsagar |
tags |
seg sts verification-needed verification-needed-bionic verification-needed-focal verification-needed-impish |
seg sts verification-done-bionic verification-done-focal verification-needed verification-needed-impish |
|
| 2022-03-09 04:29:26 |
nikhil kshirsagar |
tags |
seg sts verification-done-bionic verification-done-focal verification-needed verification-needed-impish |
seg sts verification-done-bionic verification-done-focal verification-done-impish verification-needed |
|
| 2022-03-10 17:11:24 |
Launchpad Janitor |
sosreport (Ubuntu Impish): status |
Fix Committed |
Fix Released |
|
| 2022-03-10 17:11:28 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2022-03-10 17:15:32 |
Launchpad Janitor |
sosreport (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2022-03-10 17:16:19 |
Launchpad Janitor |
sosreport (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2022-03-11 08:11:40 |
nikhil kshirsagar |
tags |
seg sts verification-done-bionic verification-done-focal verification-done-impish verification-needed |
seg sts verification-done verification-done-bionic verification-done-focal verification-done-impish |
|
