I believe there is an issue to that affect here, with no one assigned: https://github.com/apple/foundationdb/issues/567
There’s also some discussion about that in this forum post: Proposal: Don’t identify a coordinator based on its IP
I think something like that sounds reasonable enough for the reasons you’ve outlined above. I noticed that in your example, you are proposing connecting to some kind of config-vending solution rather than hard-coding the connection information into memory. I’m of two minds about this. The first is that that is probably necessary in many deploys where you might need to respond to a changing cluster file (when, for example, the coordinators change) but you also find that each time your instance is brought up, it might be on a random host from tabula rasa. But the second is that it also means that now your service is dependent on your config-vending solution being highly available. which seems suboptimal. Perhaps there is a middle ground where you have a default cluster configuration string that you default to if you cannot communicate with your config-vendor after some timeout?
But this is somewhat of a digression.
I think we’d probably not want to use temporary, in-memory files in the solution if possible (though maybe it’d be fine). In particular, I think the concern would be that it might not be easily portable to other systems. I will add that internally, most things already use what is known as the “cluster config string” (i.e., the cluster file contents) rather than the cluster file path (or file handle) as the way they connect to server processes. So I suspect that it probably wouldn’t be that hard to refactor the parts that do use the file to instead let you use a string and then most of the code probably doesn’t change that much.