Add “temporary” mode

[FGasper]

Expected behavior

It would be nice, I think, to have a mode of deployment where:

• All data is stored in temp directories.
• All subprocesses are launched non-forking, and the main process blocks; thus, a CTRL-C will cause a graceful shutdown of all processes.
• OPTIONAL: All services (e.g., mongod) bind to “port 0”, thus alleviating the need to know in advance which port to hold free.

Actual/current behavior

Right now all services start as daemons. Thus, if a test blows up without its cleanup steps, we get “leftovers” that have to be manually cleaned up. Ideally I’d like the above mode of deployment so that, regardless of how a test exits, the subprocesses go away gracefully.

---

(I may take a stab at this next time Skunkworks comes around, but in the interim I thought I’d see if the idea has appeal.)

[stennie]

Hi @FGasper,

I think launching multiple non-forking processes adds unnecessary complexity versus the current approach of forking. The data & log paths for an mlaunch deployment share a top-level base directory, so mlaunch kill and rm -rf mlaunchdir/ seems straightforward for cleaning up processes and data. If you want to use a RAM drive or preferred base path, mlaunch init --dir DIR should be useful.

As far as binding all services to port 0 goes: I'm not sure if that would work with a replica set or sharded cluster running on the same host (which would really be the main use case for mlaunch). There is a --port option to set the starting port number if you have prefer not to use the defaults or have multiple deployments running concurrently.

Regards,
Stennie

[FGasper]

@stennie My experience has been that deterministic ports/dirs lead to conflicts: I forget whether I have mongo running, which port(s), where the data dirs are, etc.

It would simplify my own use of this tool greatly if I didn’t have to worry about predetermining ports or storage, and if mlaunch stayed running as long as the mongo instances do: that way there’s minimal chance of cruft corrupting test runs or such.

mongod and mongos do both respond appropriately to --port 0 (on macOS & Linux, anyhow … not sure about Windows). The actual bound port can be found in the log.

Anyhow, thank you for your consideration. :)