Chris Marusich writes: > Christopher Allan Webber <cweb...@dustycloud.org> 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.
