Re: (Exposing?) config files and non-start/stop operations

[Christopher Allan Webber]

Ludovic Courtès writes:

> Christopher Allan Webber <address@hidden> skribis:
>
>> Chris Marusich writes:
>>
>>>>>  - Initializing a data store.  For example, in dirvish I need to run
>>>>>    a command to initialize a "vault" where I will be storing my data.
>>>>>  - Manually invoking a garbage collection utility.
>>>>>  - Manually invoking an integrity check utility.
>>>>>  - Possibly some side effect involving querying the network.
>>>>>  - Running schema migrations.
>>>>>
>>>>> All sorts of things!  Most of them (all?) involve state or side effects,
>>>>> but plenty of our most important services will be "state overlords" of
>>>>> some type.
>>>
>>> Why do those activities need to be represented as actions in Shepherd?
>>> If we're running a daemon or service that already exposes a mechanism
>>> for manually running tasks like these, then can't we just use "the usual
>>> mechanism" for doing it?  For example, if we're running a daemon that
>>> already provides a script to perform garbage collection, can't we just
>>> invoke that script?  It isn't clear to me why we would need to model
>>> domain-specific actions like that in Shepherd, although I can see why it
>>> might be convenient.  Am I missing something?
>>
>> So sure, we can run "foo-db gc" occasionally (though system
>> administrators sometimes have to run these kinds of commands by hand).
>> But what about "foo-db dumpdb"?  That's not something we just run on a
>> cronjob.  You need access to that command.  And in order for the command
>> to do the right thing, it might need access to the config file.
>
> Oh I see, so the main issue is getting a hand on that config file.
>
> In that case, yes, a Shepherd action would a good way to achieve it.
>
> It’s also a situation where adding the config file to /etc would be
> reasonable (until Shepherd actions can actually be added :-)).

True.  Though we still run, potentially, into problems where multiple
instances of some service are provided, eg multiple mediagoblin servers
or mail daemons or etc.  Though maybe a prefix/suffix could be provided
by the user to the service definition, so it would really shouw up like
/etc/mediagoblin-foosite.org

It might also be possible to do "herd config foo-db" with "config" as an
action and get back your config file to stdout.

Note: I'm interested still in exploring the shepherd actions stuff
still... though I did realize this morning that it wouldn't help in the
rare commands that have interactive input... there's no way to send
input/output in that way through the herd afaict!  Oh well, that's
probably pretty rare.

Speaking of I/O from commands, I wonder how you'd give any kind of
output back through an action to the herd?  Afaict the protocol supports
it and allows sending back "messages" that will be displayed, but
nothing uses it yet.  There's a <command-reply> record type that afaict
nothing uses at all.

>> There are some other things where we can try to initialize or run
>> migrations automatically, but that stuff can be very dangerous to just
>> do implicitly.  Now note, I *do* think we want to handle some of this
>> stuff behind the scenes as much as possible so that users don't have to
>> think about it.  But have you ever done a *really big* database schema
>> migration?
>
> I guess not ;-), but I think it may be best to simply prevent the DB
> service from starting when a migration needs to happen, and let the user
> handle it explicitly and restart the DB service when they’re done.
>
> Ludo’.

Yep!  Does require handing them a config, but I guess we've discussed
some reasonable ways to make that happen for now.

I did test out extending the etc-service-type this week; it was pretty
easy!

 - Chris