From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Allan Webber Subject: Re: (Exposing?) config files and non-start/stop operations Date: Mon, 21 Nov 2016 10:18:48 -0600 Message-ID: <877f7wbyc7.fsf@dustycloud.org> References: <87a8cuaszg.fsf@dustycloud.org> <878tsdbx2d.fsf@dustycloud.org> <87polpo2k4.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8rJ1-0005Zc-8l for guix-devel@gnu.org; Mon, 21 Nov 2016 11:18:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8rIx-0001ao-AJ for guix-devel@gnu.org; Mon, 21 Nov 2016 11:18:55 -0500 Received: from dustycloud.org ([50.116.34.160]:36592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8rIx-0001ag-55 for guix-devel@gnu.org; Mon, 21 Nov 2016 11:18:51 -0500 In-reply-to: <87polpo2k4.fsf@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: guix-devel@gnu.org 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. 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? We run into two challenges: - Now we're trying to "idempotently manage state", which it turns out is very hard (and the source of many bugs in devops tooling) - Some commands either need to be run manually occasionally, or are never automatically run (see the dumpdb example). Does this make sense? - Chris