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: Sun, 27 Nov 2016 09:39:04 -0600 Message-ID: <87twat0w6f.fsf@dustycloud.org> References: <87a8cuaszg.fsf@dustycloud.org> <878tsdbx2d.fsf@dustycloud.org> <87polpo2k4.fsf@gmail.com> <877f7wbyc7.fsf@dustycloud.org> <87poln86mx.fsf@gnu.org> <87mvgpj1kq.fsf@dustycloud.org> <87shqh57ht.fsf@gnu.org> <87fumghvdc.fsf@dustycloud.org> <87bmx2h0sr.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45532) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cB1Xq-00016e-BX for guix-devel@gnu.org; Sun, 27 Nov 2016 10:39:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cB1Xn-0008Us-2x for guix-devel@gnu.org; Sun, 27 Nov 2016 10:39:10 -0500 In-reply-to: <87bmx2h0sr.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: > Christopher Allan Webber writes: > >> So shepherd actions are probably fine for something like "herd status >> mcron" but for running slow and expensive operations, we need some way >> to expose the config file. > > The speed and cost of an operation are orthogonal to whether or not that > operation requires access to a config file. But they aren't orthogonal to whether or not it's a shepherd action, if a shepherd action is expected to be nonblocking. >> SO, the two ways to do that seem to be: >> - Populate those configs in /etc/ (maybe providing prefix/suffix option >> for multiple instances)... probably ok since we expect situations >> that need these configs to be relatively rare. > > Putting stuff into /etc seems undesirable because (1) putting things > outside the immutable store seems like an invitation to meddle with the > files, and (2) the possibility of file name conflicts exists, which you > are already aware of. However, this might be the simplest solution, so > if nothing else seems better, I think it would be reasonable to do. Those are definitely concerns (though hopefully people wouldn't be modifying things in /etc since "guix system reconfigure" will splat over any changes). >> - We could also have a shepherd action like "herd config mediagoblin" >> that would merely spit out the configuration file path... so someone >> could do something like: >> $ foo-db dump-db --config `herd config foo-db` > > This seems less desirable than putting things into /etc because it > doesn't seem to be in line with the intended use of Shepherd. My > understanding is that Shepherd's job is to nanny the system's processes. > Responding to queries about the location of the services' config files > doesn't seem germane to that job. I agree that it seems a bit strange, but no solution really seems great. However, I don't think it's totally outside the reasonable realm of shepherd. Shepherd actions are to execute some operation on a process that's running (or which could run). Returning the contextual information of what config file is being used can fit that paradigm. But it does feel a bit like a shoehorn. > As I see it, there is another possible solution: Modify the > service/daemon/tool so that it is no longer necessary to expose the > config file location in the first place. I'm still not sure which > daemon/service we're talking about here, but surely the daemon/service > knows where its configuration file is when it starts up. Surely it > could be made to remember that, if it doesn't already. Surely a tool > could be made which queries the service/daemon for that information if > necessary. Surely the service/daemon could be made to perform > operations like a database dump without being told where its own > configuration file is. And where would the configuration file be? And who would define it, when? That's effectively what imperative distributions do, and the application "knows" to look in /etc/, for some user-mutated file.