Shepherd news + planned feature removal

Shepherd news + planned feature removal

[Ludovic Courtès]

Hello Guix!

I recently pushed an updated and rebased variant of
‘wip-service-monitor’ in the Shepherd, previously discussed here:

  https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00350.html

I’m going to merge it real soon if there are no objections, with the
goal of using it as the basis for 0.10.x and hopefully soonish 1.0.x.

The main news are:

  • Services can now be in one of 4 states: stopped, starting, started,
    and stopping.  (Previously it was just started/stopped.)

  • ‘herd status SERVICE’ reports those new states.

  • ‘start’ waits if the service was already starting; ‘stop’ waits if
    the service was already being stopped.

  • Services are now started in parallel, to the extent possible.

Internally, the big change is that, in addition to a “service registry”
actor (a fiber and associated channel where it receives requests), each
service has an associated actor (likewise, a fiber) that handles
service-specific operations such as ‘start’ and ‘stop’.  I find it
aesthetically pleasing and fun to work with; incidentally, it should
sound familiar to the goblins among us.  :-)

There’s a couple of shepherd features that I’d like to remove:
“persistency” (sic), and the “unknown” service.  These things were added
in the early days of dmd ca. 2003 but they’re totally untested, likely
broken, and probably useless.  If you have objections, now’s the time to
let it be known.

Feedback welcome!

Ludo’.

Re: Shepherd news + planned feature removal

[Thompson, David]

Hi Ludo,

On Tue, Feb 21, 2023 at 5:07 PM Ludovic Courtès <ludo@gnu.org> wrote:
>
> Hello Guix!
>
> I recently pushed an updated and rebased variant of
> ‘wip-service-monitor’ in the Shepherd, previously discussed here:
>
>   https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00350.html
>
> I’m going to merge it real soon if there are no objections, with the
> goal of using it as the basis for 0.10.x and hopefully soonish 1.0.x.
>
> The main news are:
>
>   • Services can now be in one of 4 states: stopped, starting, started,
>     and stopping.  (Previously it was just started/stopped.)
>
>   • ‘herd status SERVICE’ reports those new states.
>
>   • ‘start’ waits if the service was already starting; ‘stop’ waits if
>     the service was already being stopped.
>
>   • Services are now started in parallel, to the extent possible.
>
> Internally, the big change is that, in addition to a “service registry”
> actor (a fiber and associated channel where it receives requests), each
> service has an associated actor (likewise, a fiber) that handles
> service-specific operations such as ‘start’ and ‘stop’.  I find it
> aesthetically pleasing and fun to work with; incidentally, it should
> sound familiar to the goblins among us.  :-)
>
> There’s a couple of shepherd features that I’d like to remove:
> “persistency” (sic), and the “unknown” service.  These things were added
> in the early days of dmd ca. 2003 but they’re totally untested, likely
> broken, and probably useless.  If you have objections, now’s the time to
> let it be known.
>
> Feedback welcome!

All of these changes sound like welcome ones to me!  Love the use of
actors for managing services.  Feels kinda like Goblins meets Erlang!
I hope it proves to be a robust change.

- Dave

Shepherd news + planned feature removal

[Adam Faiz]

> Hello Guix!
> 
> I recently pushed an updated and rebased variant of
> ‘wip-service-monitor’ in the Shepherd, previously discussed here:
> 
>   https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00350.html
> 
> I’m going to merge it real soon if there are no objections, with the
> goal of using it as the basis for 0.10.x and hopefully soonish 1.0.x.
> 
> The main news are:
> 
>   • Services can now be in one of 4 states: stopped, starting, started,
>     and stopping.  (Previously it was just started/stopped.)
> 
>   • ‘herd status SERVICE’ reports those new states.
> 
>   • ‘start’ waits if the service was already starting; ‘stop’ waits if
>     the service was already being stopped.
> 
>   • Services are now started in parallel, to the extent possible.
> 
> Internally, the big change is that, in addition to a “service registry”
> actor (a fiber and associated channel where it receives requests), each
> service has an associated actor (likewise, a fiber) that handles
> service-specific operations such as ‘start’ and ‘stop’.  I find it
> aesthetically pleasing and fun to work with; incidentally, it should
> sound familiar to the goblins among us.  :-)
> 
> There’s a couple of shepherd features that I’d like to remove:
> “persistency” (sic), and the “unknown” service.  These things were added
> in the early days of dmd ca. 2003 but they’re totally untested, likely
> broken, and probably useless.  If you have objections, now’s the time to
> let it be known.

I'm ok with current service state persistency being removed, since users can 
always modify a copy of the shepherd configuration file and tell the shepherd to 
load that instead, which achieves the same thing.

The 'unknown service fallback seems like a really cool feature, but if there 
isn't really any use for it, then I guess it should be removed. It can always be 
added back in if someone has a usecase for it.

I just have 1 question: Why is there a need for `herd status` to display whether 
a service is in a starting or stopping state?

 From the perspective of the shepherd, a service that is starting isn't running 
yet, and a service that is stopping isn't stopped yet.
The "starting" and "stopping" states are just an implementation detail to handle 
the shepherd being asynchronous. It's the running and stopped states that a user 
wants to know about a service.

> 
> Feedback welcome!
> 
> Ludo’.
> 

Re: Shepherd news + planned feature removal

[Liliana Marie Prikler]

Am Freitag, dem 24.02.2023 um 00:35 +0000 schrieb Adam Faiz:
> 
> From the perspective of the shepherd, a service that is starting
> isn't running yet, and a service that is stopping isn't stopped yet.
> The "starting" and "stopping" states are just an implementation
> detail to handle the shepherd being asynchronous. It's the running
> and stopped states that a user wants to know about a service.
A user might (intentionally or otherwise) run several shepherd commands
in parallel.  For instance, if herd start my-service blocks and my-
service depends on some-other-service, I can run herd status and it
will tell me:
1. that some-other-service is starting or started
2. that my-service is starting and I shouldn't try to start another

Cheers

Re: Shepherd news + planned feature removal

[Ludovic Courtès]

Hi,

Adam Faiz <adam.faiz@disroot.org> skribis:

> I just have 1 question: Why is there a need for `herd status` to
> display whether a service is in a starting or stopping state?
>
> From the perspective of the shepherd, a service that is starting isn't
> running yet, and a service that is stopping isn't stopped yet.
> The "starting" and "stopping" states are just an implementation detail
> to handle the shepherd being asynchronous. It's the running and
> stopped states that a user wants to know about a service.

The way I see it, it’s more about improving the introspection
capabilities so that users can peek into service state as known to
shepherd.  I don’t see a good reason to hide that info.

Ludo’.