Christopher Allan Webber <cweb...@dustycloud.org> writes: > 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.
I agree that's true. I admittedly don't know a lot about Shepherd (yet!), but I would think that as long as invoking "herd dump-db my-database" doesn't block Shepherd from performing its duties, the duration of that invocation shouldn't matter. However, since Ludo' explicitly said that "actions are expected to be non-blocking," I think we should probably keep the actions non-blocking. >>> 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). In my experience, people often meddle with the system config files because it is often the path of least resistance for ad-hoc changes. If you put a scary warning in there like "YOUR CHANGES WILL BE OVERRIDDEN" then maybe they're less likely to do it, but a mechanism to enforce that (e.g., by storing the config file in the immutable store) is better. >>> - 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. After thinking about it a little more, I'm not so sure I agree with what I originally said. At this point, I'm inclined to agree with Ludo', who said we should decide what to do for each service on a case-by-case basis. So, if adding an action makes more sense to you here, then let's do that. We can see if a pattern emerges over time for other services. -- Chris
signature.asc
Description: PGP signature