Christopher Allan Webber <cweb...@dustycloud.org> 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 :-)). > 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’.