4 ms·

That's all very well for just `--dry-run`, but it's still a problem if you use the method in OP to architect the entire tool (and in particular the non-dry-run

That's all very well for just `--dry-run`, but it's still a problem if you use the method in OP to architect the entire tool (and in particular the non-dry-run execution) around the existence of a `--dry-run` phase.

iudqnolq 5y ago
I don't think so? The planning stage generates something like DeleteOp(ServerSpec { tag: "foo" }).
- Smaug123 5y ago
  I think the problem is that describing it as "would have deleted 1378 servers", and then going off and deleting those 1378 servers, doesn't solve the race condition problem that leaves you with some servers left undeleted because they popped into existence after the check. With server deletion, of course, the problem is less visible because it's naturally idempotent (unless you're referring to servers by some non-unique key). In that case, you can safely just pretend the leftover servers came into existence after the entire tool came into being. Of course, if you're referring to servers by name or IP or something, then you hit exactly the problem. Concretely: I run a command that deletes all servers older than one day. The 'dry-run' section determines what servers need to be deleted and it turns out that server "foo" needs to be deleted. Elsewhere, someone spots that "foo" exists, deletes it, and creates a new server with the name "foo". Then the 'execute' flow deletes the new "foo", which is entirely not the server we wanted to delete.
  - cmeacham98 5y ago
    Your example inaccurately describes what would happen with GP's approach. Planning stage would generate `Delete(Server{CreatedBefore: 1621887357}))`. It would output something like "Deleting servers created before $time$, currently $servers$." The point is the planning stage would encode the operation being done, not a list of servers to delete.
    - Smaug123 5y ago
      Ohh, sorry - I got the wrong end of the stick entirely. Yes, in that case I'm satisfied!

iudqnolq 5y ago

I don't think so? The planning stage generates something like DeleteOp(ServerSpec { tag: "foo" }).

Smaug123 5y ago
I think the problem is that describing it as "would have deleted 1378 servers", and then going off and deleting those 1378 servers, doesn't solve the race condition problem that leaves you with some servers left undeleted because they popped into existence after the check. With server deletion, of course, the problem is less visible because it's naturally idempotent (unless you're referring to servers by some non-unique key). In that case, you can safely just pretend the leftover servers came into existence after the entire tool came into being. Of course, if you're referring to servers by name or IP or something, then you hit exactly the problem. Concretely: I run a command that deletes all servers older than one day. The 'dry-run' section determines what servers need to be deleted and it turns out that server "foo" needs to be deleted. Elsewhere, someone spots that "foo" exists, deletes it, and creates a new server with the name "foo". Then the 'execute' flow deletes the new "foo", which is entirely not the server we wanted to delete.
- cmeacham98 5y ago
  Your example inaccurately describes what would happen with GP's approach. Planning stage would generate `Delete(Server{CreatedBefore: 1621887357}))`. It would output something like "Deleting servers created before $time$, currently $servers$." The point is the planning stage would encode the operation being done, not a list of servers to delete.
  - Smaug123 5y ago
    Ohh, sorry - I got the wrong end of the stick entirely. Yes, in that case I'm satisfied!