Some questions:

• anything we should worry about with rollback states or anything like that?
• do we only want it to be per-stack (and not globally)?

concurrency_handler: error default

concurrency_handler: wait

anything we should worry about with rollback states or anything like that?

Probably. I just kept it simple for this version, but in reality it should probably not return True immediately after waiting, and instead continue down with the new stack status so that rollbacks get handled.

do we only want it to be per-stack (and not globally)?

I could go either way. I kinda lean towards per-stack just cause that's more flexible, but we could do both (per-stack overrides global default).

Re: the naming, I'm also not a huge fan. It's purpose is to configure the desired behavior when a stack is in an "in progress" state, or otherwise not updatable (CREATE_IN_PROGRESS, UPDATE_IN_PROGRESS, DELETE_IN_PROGRESS, UPDATE_COMPLETE_CLEANUP_IN_PROGRESS). All of these have IN_PROGRESS in the name, which is why I went with in_progress.

Just brainstorming:

in_progress: wait
in_progress_behavior: wait
operation_in_progress: wait
not_ready: wait

concurrency_handler makes me think threading, and not necessarily accurate (it may just be that someone did something manually, and not necessarily a result of concurrent stacker builds).

I've changed the implementation slightly so that it's all implemented within _launch_stack, instead of in the aws provider. This should be better because:

1. SIGTERM/SIGINT works properly
2. It let's us update the status of the stack to indicate that stacker is waiting

I vote for in_progress_behavior:

Cool, I like in_progress_behavior too. Updated to that.

Yeah, in_progress_behavior is probably the most descriptive/easy to understand. It's long, and that's annoying, but I think it's the best.

@ejholmes could we get this PR rebased and merged in? We had people in the chatroom asking for it.