| 2019-05-09 20:55:24 |
Dan Hill |
bug |
|
|
added bug |
| 2019-05-09 21:00:40 |
Dan Hill |
sosreport (Ubuntu): milestone |
|
eoan-updates |
|
| 2019-05-09 21:01:06 |
Dan Hill |
sosreport (Ubuntu): milestone |
eoan-updates |
|
|
| 2019-05-09 21:01:34 |
Dan Hill |
nominated for series |
|
Ubuntu Cosmic |
|
| 2019-05-09 21:01:34 |
Dan Hill |
bug task added |
|
sosreport (Ubuntu Cosmic) |
|
| 2019-05-09 21:01:34 |
Dan Hill |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-05-09 21:01:34 |
Dan Hill |
bug task added |
|
sosreport (Ubuntu Bionic) |
|
| 2019-05-09 21:01:34 |
Dan Hill |
nominated for series |
|
Ubuntu Trusty |
|
| 2019-05-09 21:01:34 |
Dan Hill |
bug task added |
|
sosreport (Ubuntu Trusty) |
|
| 2019-05-09 21:01:34 |
Dan Hill |
nominated for series |
|
Ubuntu Eoan |
|
| 2019-05-09 21:01:34 |
Dan Hill |
bug task added |
|
sosreport (Ubuntu Eoan) |
|
| 2019-05-09 21:01:34 |
Dan Hill |
nominated for series |
|
Ubuntu Disco |
|
| 2019-05-09 21:01:34 |
Dan Hill |
bug task added |
|
sosreport (Ubuntu Disco) |
|
| 2019-05-09 21:01:34 |
Dan Hill |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-05-09 21:01:34 |
Dan Hill |
bug task added |
|
sosreport (Ubuntu Xenial) |
|
| 2019-05-09 21:02:16 |
Dan Hill |
sosreport (Ubuntu Xenial): assignee |
|
Dan Hill (hillpd) |
|
| 2019-05-09 21:02:19 |
Dan Hill |
sosreport (Ubuntu Bionic): assignee |
|
Dan Hill (hillpd) |
|
| 2019-05-09 21:02:22 |
Dan Hill |
sosreport (Ubuntu Cosmic): assignee |
|
Dan Hill (hillpd) |
|
| 2019-05-09 21:02:25 |
Dan Hill |
sosreport (Ubuntu Disco): assignee |
|
Dan Hill (hillpd) |
|
| 2019-05-09 21:02:27 |
Dan Hill |
sosreport (Ubuntu Eoan): assignee |
|
Dan Hill (hillpd) |
|
| 2019-05-09 21:02:30 |
Dan Hill |
sosreport (Ubuntu Trusty): assignee |
|
Dan Hill (hillpd) |
|
| 2019-05-09 21:02:44 |
Dan Hill |
sosreport (Ubuntu Trusty): importance |
Undecided |
Low |
|
| 2019-05-09 21:02:47 |
Dan Hill |
sosreport (Ubuntu Xenial): importance |
Undecided |
Low |
|
| 2019-05-09 21:02:51 |
Dan Hill |
sosreport (Ubuntu Bionic): importance |
Undecided |
Low |
|
| 2019-05-09 21:02:57 |
Dan Hill |
sosreport (Ubuntu Cosmic): importance |
Undecided |
Low |
|
| 2019-05-09 21:02:59 |
Dan Hill |
sosreport (Ubuntu Disco): importance |
Undecided |
Low |
|
| 2019-05-09 21:03:02 |
Dan Hill |
sosreport (Ubuntu Eoan): importance |
Undecided |
Low |
|
| 2019-05-09 21:03:19 |
Dan Hill |
tags |
|
sts |
|
| 2019-05-09 21:09:51 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2019-05-09 21:10:01 |
Eric Desrochers |
bug |
|
|
added subscriber STS Sponsors |
| 2019-05-09 21:12:15 |
Dan Hill |
sosreport (Ubuntu Eoan): status |
New |
In Progress |
|
| 2019-05-10 16:35:46 |
Eric Desrochers |
description |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream and will be fixed by the juju 2.x refactor:
https://github.com/sosreport/sos/issues/1653
This is a stop-gap tracking the removal of the juju-db service restart code in
existing sosreport releases.
[Test Case]
* Install sosreport
* Run sosreport, ensuring that the juju plugin is exercised.
* Confirm the juju-db service was not restarted, and mongoexport data captured.
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect
any data. |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Install sosreport
* Look mongod PID before
** pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
* Confirm the juju-db service was not restarted, and mongoexport data captured.
* Look mongod PID after
** pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and juju-db reside.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect
any data. |
|
| 2019-05-10 17:35:08 |
Eric Desrochers |
description |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Install sosreport
* Look mongod PID before
** pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
* Confirm the juju-db service was not restarted, and mongoexport data captured.
* Look mongod PID after
** pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and juju-db reside.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect
any data. |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport
* Look mongod PID before
** $ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
* Confirm the juju-db service was not restarted, and mongoexport data captured.
* Look mongod PID after
** $ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins. |
|
| 2019-05-10 19:30:34 |
Eric Desrochers |
sosreport (Ubuntu Trusty): status |
New |
Won't Fix |
|
| 2019-05-10 19:47:34 |
Eric Desrochers |
description |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport
* Look mongod PID before
** $ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
* Confirm the juju-db service was not restarted, and mongoexport data captured.
* Look mongod PID after
** $ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins. |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport
* Look mongod PID before
** $ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
* Confirm the juju-db service was not restarted, and mongoexport data captured.
* Look mongod PID after
** $ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins.
[Other information]
We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment.
Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian.
Actually, sosreport 3.7 micro-release is waiting on this via LP: #1825010. |
|
| 2019-05-10 19:48:48 |
Eric Desrochers |
description |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport
* Look mongod PID before
** $ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
* Confirm the juju-db service was not restarted, and mongoexport data captured.
* Look mongod PID after
** $ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins.
[Other information]
We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment.
Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian.
Actually, sosreport 3.7 micro-release is waiting on this via LP: #1825010. |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport
* Look mongod PID before
** $ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
* Confirm the juju-db service was not restarted, and mongoexport data captured.
* Look mongod PID after
** $ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins.
[Other information]
We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment.
Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian.
Actually, sosreport 3.7 micro-release is blocked waiting for this refactoring to be completed (LP: #1825010). |
|
| 2019-06-05 14:49:00 |
Eric Desrochers |
removed subscriber STS Sponsors |
|
|
|
| 2019-11-11 15:34:48 |
Eric Desrochers |
sosreport (Ubuntu): assignee |
Dan Hill (hillpd) |
Eric Desrochers (slashd) |
|
| 2019-11-11 15:34:55 |
Eric Desrochers |
sosreport (Ubuntu): status |
In Progress |
Fix Released |
|
| 2019-11-11 15:35:02 |
Eric Desrochers |
sosreport (Ubuntu Cosmic): status |
New |
Won't Fix |
|
| 2019-11-11 15:35:09 |
Eric Desrochers |
sosreport (Ubuntu Eoan): assignee |
Dan Hill (hillpd) |
Eric Desrochers (slashd) |
|
| 2019-11-11 15:35:14 |
Eric Desrochers |
sosreport (Ubuntu Disco): assignee |
Dan Hill (hillpd) |
Eric Desrochers (slashd) |
|
| 2019-11-11 15:35:16 |
Eric Desrochers |
sosreport (Ubuntu Cosmic): assignee |
Dan Hill (hillpd) |
|
|
| 2019-11-11 15:35:19 |
Eric Desrochers |
sosreport (Ubuntu Bionic): assignee |
Dan Hill (hillpd) |
Eric Desrochers (slashd) |
|
| 2019-11-11 15:35:22 |
Eric Desrochers |
sosreport (Ubuntu Xenial): assignee |
Dan Hill (hillpd) |
Eric Desrochers (slashd) |
|
| 2019-11-11 15:35:27 |
Eric Desrochers |
sosreport (Ubuntu Disco): status |
New |
In Progress |
|
| 2019-11-11 15:35:29 |
Eric Desrochers |
sosreport (Ubuntu Bionic): status |
New |
In Progress |
|
| 2019-11-11 15:35:32 |
Eric Desrochers |
sosreport (Ubuntu Xenial): status |
New |
In Progress |
|
| 2019-11-11 16:17:44 |
Eric Desrochers |
sosreport (Ubuntu Xenial): importance |
Low |
Medium |
|
| 2019-11-11 16:17:47 |
Eric Desrochers |
sosreport (Ubuntu Bionic): importance |
Low |
Medium |
|
| 2019-11-11 16:17:51 |
Eric Desrochers |
sosreport (Ubuntu Disco): importance |
Low |
Medium |
|
| 2019-11-11 16:17:54 |
Eric Desrochers |
sosreport (Ubuntu Eoan): importance |
Low |
Medium |
|
| 2019-11-11 16:18:48 |
Eric Desrochers |
description |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport
* Look mongod PID before
** $ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
* Confirm the juju-db service was not restarted, and mongoexport data captured.
* Look mongod PID after
** $ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins.
[Other information]
We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment.
Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian.
Actually, sosreport 3.7 micro-release is blocked waiting for this refactoring to be completed (LP: #1825010). |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport
* Look mongod PID before
** $ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
* Confirm the juju-db service was not restarted, and mongoexport data captured.
* Look mongod PID after
** $ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins.
If any regression, it will be way less worse than current situation, where daemon are susceptible to be restarted.
[Other information]
We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment.
Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian.
Actually, sosreport 3.7 micro-release is blocked waiting for this refactoring to be completed (LP: #1825010). |
|
| 2019-11-11 16:20:38 |
Eric Desrochers |
description |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport
* Look mongod PID before
** $ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
* Confirm the juju-db service was not restarted, and mongoexport data captured.
* Look mongod PID after
** $ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins.
If any regression, it will be way less worse than current situation, where daemon are susceptible to be restarted.
[Other information]
We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment.
Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian.
Actually, sosreport 3.7 micro-release is blocked waiting for this refactoring to be completed (LP: #1825010). |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport
* Look mongod PID before
** $ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
* Confirm the juju-db service was not restarted, and mongoexport data captured.
* Look mongod PID after
** $ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins.
If any regression, it will be way less worse than current situation, where daemon are susceptible to be restarted.
[Other information]
We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment.
Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian.
Actually, sosreport 3.8 micro-release is blocked waiting for this refactoring to be completed (LP: #1825010). |
|
| 2019-11-11 16:29:06 |
Eric Desrochers |
bug |
|
|
added subscriber Bryan Quigley |
| 2019-11-11 20:20:52 |
Eric Desrochers |
sosreport (Ubuntu Trusty): assignee |
Dan Hill (hillpd) |
|
|
| 2019-11-11 20:24:01 |
Eric Desrochers |
description |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport
* Look mongod PID before
** $ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
* Confirm the juju-db service was not restarted, and mongoexport data captured.
* Look mongod PID after
** $ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins.
If any regression, it will be way less worse than current situation, where daemon are susceptible to be restarted.
[Other information]
We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment.
Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian.
Actually, sosreport 3.8 micro-release is blocked waiting for this refactoring to be completed (LP: #1825010). |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport (if not present already)
$ sudo apt-get install sosreport -y
* Look mongod PID before
$ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
$ sosreport -a
and/or
$ sosreport -o juju
* Confirm the juju-db service was not restarted, and mongoexport data captured by looking mongod PID after
$ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins.
If any regression, it will be way less worse than current situation, where daemon are susceptible to be restarted.
[Other information]
We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment.
Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian.
Actually, sosreport 3.8 micro-release is blocked waiting for this refactoring to be completed (LP: #1825010). |
|
| 2019-11-11 20:26:22 |
Eric Desrochers |
description |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport (if not present already)
$ sudo apt-get install sosreport -y
* Look mongod PID before
$ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
$ sosreport -a
and/or
$ sosreport -o juju
* Confirm the juju-db service was not restarted, and mongoexport data captured by looking mongod PID after
$ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins.
If any regression, it will be way less worse than current situation, where daemon are susceptible to be restarted.
[Other information]
We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment.
Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian.
Actually, sosreport 3.8 micro-release is blocked waiting for this refactoring to be completed (LP: #1825010). |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport (if not present already)
$ sudo apt-get install sosreport -y
* Look mongod PID before
$ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
$ sosreport -a # Should detect it if /usr/bin/juju' or '/usr/bin/juju-run' are found
and/or
$ sosreport -o juju # In a snap package env, it's possible sosreport doesn't detect it and the plugin would need to be enforce.
* Confirm the juju-db service was not restarted, and mongoexport data captured by looking mongod PID after
$ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins.
If any regression, it will be way less worse than current situation, where daemon are susceptible to be restarted.
[Other information]
We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment.
Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian.
Actually, sosreport 3.8 micro-release is blocked waiting for this refactoring to be completed (LP: #1825010). |
|
| 2019-11-11 21:38:01 |
Eric Desrochers |
description |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport (if not present already)
$ sudo apt-get install sosreport -y
* Look mongod PID before
$ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
$ sosreport -a # Should detect it if /usr/bin/juju' or '/usr/bin/juju-run' are found
and/or
$ sosreport -o juju # In a snap package env, it's possible sosreport doesn't detect it and the plugin would need to be enforce.
* Confirm the juju-db service was not restarted, and mongoexport data captured by looking mongod PID after
$ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins.
If any regression, it will be way less worse than current situation, where daemon are susceptible to be restarted.
[Other information]
We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment.
Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian.
Actually, sosreport 3.8 micro-release is blocked waiting for this refactoring to be completed (LP: #1825010). |
[Impact]
The juju plugin will stop and start the juju-db service during data collection.
sosreport should not impact running services, or attempt to recover them.
This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1]
This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases.
[0] - https://github.com/sosreport/sos/issues/1653
[1] - https://github.com/sosreport/sos/pull/1670
[Test Case]
* Make sure you are in the juju controller.
* Install sosreport (if not present already)
$ sudo apt-get install sosreport -y
* Look mongod PID before
$ pidof mongod
* Run sosreport, ensuring that the juju plugin is exercised
$ sosreport -a # Should detect it if /usr/bin/juju' or '/usr/bin/juju-run' are found
and/or
$ sosreport -o juju # In a snap package env, it's possible sosreport doesn't detect it and the plugin would need to be enforce.
* Confirm the juju-db service was not restarted, and mongoexport data captured by looking mongod PID after
$ pidof mongod
Check for errors while running, or in /tmp/sosreport-*/sos_logs/
The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides.
[Regression Potential]
* Risk is low.
* Change is limited in scope to the juju plugin.
* Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins.
If any regression, it will be way less worse than current situation, where daemon are susceptible to be restarted. It's not sosreport responsability to take action on daemons, it should only monitor it and report back to users via its respective plugin.
[Other information]
We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment.
Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian.
Actually, sosreport 3.8 micro-release is blocked waiting for this refactoring to be completed (LP: #1825010). |
|
| 2019-11-11 21:41:09 |
Eric Desrochers |
bug |
|
|
added subscriber David Negreira |
| 2019-11-14 15:25:49 |
Łukasz Zemczak |
sosreport (Ubuntu Eoan): status |
In Progress |
Fix Committed |
|
| 2019-11-14 15:25:52 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-11-14 15:25:54 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2019-11-14 15:25:56 |
Łukasz Zemczak |
tags |
sts |
sts verification-needed verification-needed-eoan |
|
| 2019-11-14 15:27:24 |
Łukasz Zemczak |
sosreport (Ubuntu Disco): status |
In Progress |
Fix Committed |
|
| 2019-11-14 15:27:29 |
Łukasz Zemczak |
tags |
sts verification-needed verification-needed-eoan |
sts verification-needed verification-needed-disco verification-needed-eoan |
|
| 2019-11-14 15:32:53 |
Łukasz Zemczak |
sosreport (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2019-11-14 15:32:59 |
Łukasz Zemczak |
tags |
sts verification-needed verification-needed-disco verification-needed-eoan |
sts verification-needed verification-needed-bionic verification-needed-disco verification-needed-eoan |
|
| 2019-11-14 15:34:47 |
Łukasz Zemczak |
sosreport (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2019-11-14 15:34:52 |
Łukasz Zemczak |
tags |
sts verification-needed verification-needed-bionic verification-needed-disco verification-needed-eoan |
sts verification-needed verification-needed-bionic verification-needed-disco verification-needed-eoan verification-needed-xenial |
|
| 2019-11-14 17:14:31 |
Eric Desrochers |
tags |
sts verification-needed verification-needed-bionic verification-needed-disco verification-needed-eoan verification-needed-xenial |
sts verification-done-bionic verification-needed verification-needed-disco verification-needed-eoan verification-needed-xenial |
|
| 2019-11-18 17:01:49 |
Eric Desrochers |
tags |
sts verification-done-bionic verification-needed verification-needed-disco verification-needed-eoan verification-needed-xenial |
sts verification-done-bionic verification-done-disco verification-done-eoan verification-done-xenial verification-needed |
|
| 2019-11-21 08:08:21 |
Launchpad Janitor |
sosreport (Ubuntu Eoan): status |
Fix Committed |
Fix Released |
|
| 2019-11-21 08:08:26 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-11-21 09:13:09 |
Launchpad Janitor |
sosreport (Ubuntu Disco): status |
Fix Committed |
Fix Released |
|
| 2019-11-21 09:19:55 |
Launchpad Janitor |
sosreport (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-11-21 09:21:29 |
Launchpad Janitor |
sosreport (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
