# rpm-ostree and systemd-inhibitors

* [JL] UX of users using sd-inhibitors does not look great
* [JL] I'd like to have the machine *not* block forever if there is an inhibitor stuck
* [JL] this seems to come from a Zincati request, but haven't seen it outside of that
* [CW] there aren't many other things doing auto-updates so far
* [CW] OCP customers are segmenting nodes into different MachinePools to coordinate updates
* [CW] I'd like to just have sd-inhibitors as a useful primitive, no matter what's the driver
* [JL] let's draw an example: a custom updating every month; should they keep a month-long inhibitors
* [CW] IMHO yes; also because MCO can now do reboot-less changes
* [LB] in FCOS world, no need to keep the inhibitor for a month, you can have dedicated strategies for that
* [JL] yes, it looks like a bit of race-y primitive, especially if there are multiple upgrades pending (i.e. barriers)
* [LB] right now we are only considering rpm-ostree, but we can add logic at higher levels too (Zincati & MCO)
* [CW] I'd like to have blocking inhibitors as a reliable primitive, not happy with rpm-ostree declaring an arbitrary timeout
* [CW] MCO could be a bit smarter and mirror inhibitors/annotations to steer MCO away
* [LB] we can layer stuff:
* a timeout at the high-level (MCO / Zincati)
* respecting blocks at the low-level by default (rpm-ostree)
* a manual override to bypass blocks within rpm-ostree
* [LB] last point possibly not worth, just rebooting the node will make any stuck block-inhibitor disappear
* [JL] we should respect inhibitors at the OS level, without timeout or anything
* [CW] rpm plugins knows how to use sd-inhibitors, we should make sure we are not deadlocking
* [JL] we can experiment with the Zincati flow only, first
* [LB] instead of starting to tackle this in rpm-ostree, we can do the some changed in MCO/Zincati to get an idea about real-world usage right now
* [JL/CW] there are multiple update paths in MCO, and some of them do not require a drain+reboot
* [KF] not sure which direction to go from here
* [JL] a PR should be ok, if only Zincati goes through that codeflow
* [CW] should rpm-ostree have a flag to ignore block-inhibitors?
* [KF] my PR may likely interact with other consumers too
* [KF] but it sounds like is ok to have rpm-ostree always respect block inhibitors
* [KF] for later, whether we need a flag to ignore them
* [JL] possibly not, it doesn't look very useful as a UX flow
* [JL] for the Zincati flow, we still have no way for users to own the manual flow, but it would be good
* [LB] ack, but I wouldn't mix into this discussion
* [CW] MCO changes not a top priority right now, we can leave them for later