Activity log for bug #1875564

Date Who What changed Old value New value Message
2020-04-28 07:18:16 Didier Roche-Tolomelli bug added bug
2020-04-28 07:21:28 Didier Roche-Tolomelli zsys (Ubuntu): status New Triaged
2020-04-28 07:21:31 Didier Roche-Tolomelli zsys (Ubuntu): importance Undecided High
2020-05-06 02:08:00 satmandu bug added subscriber satmandu
2020-06-03 00:38:52 Launchpad Janitor zsys (Ubuntu): status Triaged Fix Released
2020-06-09 07:54:18 Didier Roche-Tolomelli description The client can timeout while the daemon is still doing a lot of active work. There are 3 cases to take into account: - daemon not started: give a timeout for the daemon to start before the client exits. Ideally, we would pulse back to the client, but the entrypoint isn’t reached out yet - once the call starts: If other calls are in progress and there is mutex, ideally pulse it to the client (or give a new timeout) - when it’s our turn: the pulse to the daemon can be done by the log progress which we will thus always send to the client. Note that if we wait for too long, we can imagine a pulsing progress bar on the CLI with which steps we are at. This needs to change GRPC messages back but will drastically reduce timeouts that people can get when having a lot of datasets or in code path we didn’t optimize yet. [Impact] * On slow system, zsysctl client can timeout while the daemon is still doing a lot of active work. * The daemon has now 2 phases: - Not started: specific timeout for the daemon to start before the client exits. - After startup, when proceeding client request: pulse in the grpc command from the daemon when any log is processed (just replaced by pulse bytes). [Test Case] * 1. Create a bunch of datasets so that requests always timeout * 2. Upgrade to the new zsys version * 3. Redo the same request -> it should be slow to execute but don’t timeout. [Regression Potential] * GRPC exchange hasn’t changed * However, we are now sending "." in non debug mode to the client to pulse progress. * We were already running a lot of command with -vv, sending more data (debug logs) --- The client can timeout while the daemon is still doing a lot of active work. There are 3 cases to take into account: - daemon not started: give a timeout for the daemon to start before the client exits. Ideally, we would pulse back to the client, but the entrypoint isn’t reached out yet - once the call starts:  If other calls are in progress and there is mutex, ideally pulse it to the client (or give a new timeout) - when it’s our turn: the pulse to the daemon can be done by the log progress which we will thus always send to the client. Note that if we wait for too long, we can imagine a pulsing progress bar on the CLI with which steps we are at. This needs to change GRPC messages back but will drastically reduce timeouts that people can get when having a lot of datasets or in code path we didn’t optimize yet.
2020-06-09 07:55:32 Didier Roche-Tolomelli nominated for series Ubuntu Focal
2020-06-09 07:55:32 Didier Roche-Tolomelli bug task added zsys (Ubuntu Focal)
2020-06-09 07:55:38 Didier Roche-Tolomelli zsys (Ubuntu Focal): importance Undecided High
2020-06-09 07:55:43 Didier Roche-Tolomelli zsys (Ubuntu Focal): assignee Didier Roche (didrocks)
2020-06-09 07:55:47 Didier Roche-Tolomelli zsys (Ubuntu): assignee Didier Roche (didrocks)
2020-06-19 06:36:50 Timo Aaltonen zsys (Ubuntu Focal): status New Fix Committed
2020-06-19 06:36:51 Timo Aaltonen bug added subscriber Ubuntu Stable Release Updates Team
2020-06-19 06:36:54 Timo Aaltonen bug added subscriber SRU Verification
2020-06-19 06:36:57 Timo Aaltonen tags verification-needed verification-needed-focal
2020-06-24 12:27:28 Jean-Baptiste Lallement tags verification-needed verification-needed-focal verification-done verification-done-focal
2020-07-02 08:29:32 Launchpad Janitor zsys (Ubuntu Focal): status Fix Committed Fix Released
2020-07-02 08:30:05 Łukasz Zemczak removed subscriber Ubuntu Stable Release Updates Team