On Tue, Mar 17, 2020 at 2:10 PM Ben Cotton <bcotton(a)redhat.com> wrote:
On Tue, Mar 17, 2020 at 4:48 AM Kamil Paral <kparal(a)redhat.com>
> All system services present after installation with one
release-blocking package sets must not time out frequently or regularly
when they are being stopped during system reboot/shutdown.
I like it generally, but I worry we'll get hung up on the
of "frequently" or "regularly". For shutdown in particular, I'm
concerned with service timeouts (granted, I'm not paying for my
compute by the minute).
The problem is not in the timeout itself, but when you need to wait for it.
If I do 30 system reboots a day, because I test stuff, a 90 second timeout
is suddenly a lot of time :) As a regular user, when I want to shut down
the computer and leave, and the system just doesn't, and I need to wait 2
minutes before it does, I get annoyed. Or when I want to reboot to a
different operating system, etc. It's those cases where you wait for it,
I'm leaning toward something like
"predictably" or "reliably" (which is an awkward use of the word).
I'm all for finding better words. "Reliably" might be confusing :-) I want
to cover scenarios where it covers very frequently (e.g. in 70% of
shutdowns), or deterministically (e.g. for all VMs, but not bare metals),
and discuss those. I think we can't go for a clear definition here that
would allow us to specify an exact scenario when to block and when don't.
As an example which problems could be found and discussed, I have a
suspicion that PackageKit hangs if you try to reboot the machine too early
after it starts up. Likely not a blocker, because it's not a too frequent
use case, but it could be discussed. Or imagine PackageKit hanging every
time you perform some particular operation, like a package install. That
could be a more viable candidate for a blocker.
Basically, it's not a blocker unless it does it every time.
This is probably the only exact scenario where we could make it a clear
blocker, no discussion needed. But it also means no discussion possible. If
we say "every time", as Frantisek proposed as well, we'll likely use this
criterion once in a few years, and certainly not now against spice-vdagent.
Because it doesn't time out every time, it times out every time just on
VMs. That is a condition, i.e. it is not "every time".
We can have such a criterion for sure, I just think it's not that useful.
I'd rather have one that gives us some leeway to discuss and decide how
important the issue is. Which means including "frequently",
"predictably" or something along those lines.