Add support for not allowing two deployments in parallel about deploy

[teaforthecat]

if you say --fork 1 on the command line that will do it right?

[ricardclau]

@teaforthecat --forks 1 will make Ansible connect to 1 host at a time, but the goal for this issue is preventing 2 people deploying at the same time.

Imagine for instance a distributed team deploying to 100 nodes in groups of 10... this is a relatively long process and we should prevent a second deployment until the first one has finished in all the nodes

[teaforthecat]

ah I see sorry. ok well how about this - wait_for: path=lock state=absent but since we have an atomic change with the current symlink is this really valuable? I guess if the inventory did not have a consistent order, some hosts could end up with a different release. This seems strange though. I'm thinking the responsibility should be at a higher level. I'm thinking the lock should live in Jenkins or Rundeck or... (do you have any other suggestions for an execution manager?)

[ricardclau]

I have thought a bit about this and I think there is no easy way to achieve it.

If all the deployments are originated from the same box (a Jenkins machine or something similar) the lock file strategy would possibly work but if a team is allowing any developer to deploy from any location the only way to do a common distributed lock is to have something like Zookeeper or Redis doing that function.

And I honestly think this is beyond the scope of a deployment tool and it really depends on every organisation policies.

We can add the lock file as a best effort but I am not sure it is worth it. Thoughts? @teaforthecat @carlosbuenosvinos @theUniC @ajgarlag

[teaforthecat]

I agree. If this is a problem, you probably have enough resources to spin up a deployer node. (I'd recommend Rundeck so far)

[ajgarlag]

I agree too. For me, this feature is beyond the scope of the tool.

[cbrunnkvist]

Totally agree with @ricardclau, it is a deployment process / organizational problem, not something that can be solved by a lockfile.

While it could save someone's donkey during a simple single-node deployment, I am quite sure that such a feature would cause much more inconvenience (in the form of stale/leftover locks) for others than what is gained.

You'll get into all sorts of other parallelism problems (DB migrations, LB configs) that are way out of scope for this "deploy" role, that are better solved at the playbook level.

[ricardclau]

Closing the issue according to the discussion