[ClusterLabs] Fuzzy/misleading references to "restart" of a resource
Andrei Borzenkov
arvidjaar at gmail.com
Thu Dec 5 02:41:39 EST 2019
On Thu, Dec 5, 2019 at 1:04 AM Jan Pokorný <jpokorny at redhat.com> wrote:
>
> On 04/12/19 21:19 +0100, Jan Pokorný wrote:
> > OTOH, this enforced split of state transitions is perhaps what makes
> > the transaction (comprising perhaps countless other interdependent
> > resources) serializable and thus feasible at all (think: you cannot
> > nest any further handling -- so as to satisfy given constraints -- in
> > between stop and start when that's an atom, otherwise), and that's
> > exactly how, say, systemd approaches that, likely for that very reason:
> > https://github.com/systemd/systemd/commit/6539dd7c42946d9ba5dc43028b8b5785eb2db3c5
>
> Yet, systemd started to allow for certain stop-start ("restart")
> optimizations at "stop" phase, I've just learnt:
> https://github.com/systemd/systemd/pull/13696#discussion_r330186864
> But it doesn't merge/atomicize the two discrete steps, still.
>
systemd development consists of series of ad hoc single use case
extensions, each done completely isolated, without considering impact
on other parts which is usually "fixed" by adding yet another ad hoc
extension. I do not think that is the best example to follow.
> OCF could possibly be amended to allow for a similar semantic
> indication of "stop to be reversed shortly on this very node if
> things go well" if there was a tangible use case, say using
> "stop-with-start-pending" action instead of "stop"
> (and the amendment possibly building on an idea of addon profiles
> https://github.com/ClusterLabs/OCF-spec/issues/17 if there was
> an actual infrastructure for that and not just a daydreaming).
>
I do not see how it is possible to shorthand resource restart. Cluster
resource manager manages not isolated resources, but groups of
interdependent resources. In general it is impossible to restart
single resource without coordinate restart of multiple resources. And
this should happen in defined order (you cannot "restart" mount point
without stopping any user of it first).
Moreover, restart is expected to clean up resources and actually
result in pristine state. This is implicit assumption.
More information about the Users
mailing list