Christopher Allan Webber <cweb...@dustycloud.org> skribis: > Ludovic Courtès writes:
[...] >> The protocol currently is just: you connect, you send a request, you get >> a reply, and you disconnect. Actions are expected to be non-blocking. > > Okay, an expectation of non-blocking behaviour is useful to know. > Especially because I'm not sure it's a guarantee we can provide. Eg, > imagine one of the previous commands, such as dumpdb or gc, on a really > large database. That could block for a bit. > > So shepherd actions are probably fine for something like "herd status > mcron" but for running slow and expensive operations, Right. > we need some way to expose the config file. Could be. > 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. > - 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` > > WDYT? Adding a ‘config’ action where we see fit would certainly make sense, yes. I guess it’ll have to be decided on a case-by-case basis, and perhaps we’ll see that this pattern makes sense for a whole class of services. Ludo’.
