bug#55898: Services depending on new Shepherd features may fail until reboot

[Ludovic Courtès]

Howdy!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> I had something different on mind; I was thinking of some added field to
> our shepherd-service object where the minimal version of Shepherd
> required could be specified, e.g. "0.9.1".
>
> The check could be abstracted in the shepherd-service implementation,
> avoiding services writers to handle that by themselves in *each* service
> requiring so.

Hmm I see.

> The benefit would be an improved user experience, and cleaner service
> code.  Upon reconfiguring a machine not yet equipped with a new enough
> Shepherd, Shepherd could print:
>
> The x, y and z services won't be started until the next reboot, as they
> require a newer Shepherd version.
>
> Instead of seeing the new services fail to run without (for the end
> user) without any obvious reason.

Currently, new services don’t fail to run: we arrange so that new
services always “work”, whether they’re talking to an old shepherd or a
new one.  The user experience (bugs aside) should be good: services are
always reloaded.

IIUC, in the model you propose, we’d sacrifice this, by admitting that
in some cases we just won’t load services live and instead tell users to
reboot; the benefit would be cleaner service code.

It’s a tradeoff; the cost/benefit ratio is not obvious to me.

Thanks for explaining!

Ludo’.