Integrate triggers into core?

[russroy]

I think one way to view Vagrant is as a programmable state-machine for VM environments. Viewed as such the ability to attach custom actions triggered to a state transition before, after, or in place of the existing canned vagrant actions is crucial to full programmability.

We do have the vagrant-triggers plugin which seeks fill this hole. It's a nice addition but I see some shortcomings to its embodiment as a plugin:

1. triggers is a pretty generic concept and central to the state-machine conceptualization - it belongs in the core

2. People don't alway think to look for a plugin to augment vagrant functionality. Instead they'll glom on some ad hoc solution. Putting functionality in the core gives it more "visibility".

3. Putting the functionality in the core might help to mitigate the occurrence of inter-plugin compatibility issues such as this triggers are ignored when provider is 'aws' mitchellh/vagrant-aws#233

[marnovdm]

+1, learned about vagrant-triggers through your suggestion. Would be really nice to have something like this in the core!

[mitchellh]

I agree, this is a pretty common feature. Tagged.

[emyl]

WOW! I'm really honored you want to merge triggers into core!

@mitchellh if and when you feel like, let me know if I can help you in integrating the plugin, I'd be very pleased to do it!

[russroy]

I think it's worth reflecting a bit about triggers for multi-machine environments.

Right now the plugin implements:

"Associate this action block, with this event, for this machine(s)"

Also useful would be:

"Associate this action block, with this event, once for all machines."

ie. sort of a "global" trigger

One use case: setup (before 'up') and cleanup (after 'destroy') operations that apply cluster wide (eg. alloc/dealloc a subnet resource in aws ec2) instead of for each machine individually.

Also: It would be useful to be able to get at state info or other machine metadata from within an action block (Eg. to conditionalize an 'up' associated action based upon created/not_created state.)

There may be other stuff too ... but those spring most readily to mind.

[trajano]

My use case would be to run docker swarm leave before it gets destroyed rather than doing it manually.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.