Cleanup Tasks for Shell Provisioner

[jeremyfelt]

Support for cleanup tasks was added via #1302 in Vagrant 1.3.0 and only the Chef provisioner was given a built in method to handle this functionality.

It would be excellent if the built in shell provisioner also had the ability to run either an inline script or file on vagrant destroy.

[mitchellh]

You mean you want a script to run on the host?

[jeremyfelt]

Yes, that would be ideal. It is also entirely possible that I'm thinking about this backward and I haven't handled kill scripts correctly yet.

[thasmo]

A pre-destroy script kinda would be cool, so it would be possible to export data before the VM is destroyed.

[BlinkyStitt]

This would be great.

I'm thinking something like:

config.vm.cleanup :shell, :inline => "echo hello world"

For now, I'm looking at using https://github.com/emyl/vagrant-triggers

[jmbertucci]

I could use a way to call a guest side script (similar to provision) that was run as part of the destroy process.

config.vm.cleanup :shell, :path => "cleanup.sh"

vagrant-triggers is nice but it's a host side script. I'd like to use a guest side script.

[arosenhagen]

+1 for this. pre-destroy script to backup db of guest (in case one accidentally deletes the VM)

[thedavidmeister]

I have files that are written to a synced folder (Drupal's settings.php file) during provisioning that, if they aren't deleted during destroy, cause errors next time I run up.

[dixhuit]

Currently relying increasingly on vagrant-triggers but would really like to see a plugin-less option become available beyond Chef (we're using Ansible).

[tjeffree]

Same as @thedavidmeister :

I have files that are written to a synced folder (Drupal's settings.php file) during provisioning that, if they aren't deleted during destroy, cause errors next time I run up.

My pear files end up in a shared folder and need cleaning up before running provision/up again. A quick teardown script would be a big plus.

[kadaan]

Am I correct that this can be done today with the vagrant-triggers plugin?

[gtmtech]

The vagrant triggers plugin is not quite good enough for all usecases.

[kadaan]

Can you give an example of some that it doesn't satisfy?

On Nov 7, 2014, at 9:23 AM, Geoff Meakin [email protected] wrote:

The vagrant triggers plugin is not quite good enough for all usecases.

—
Reply to this email directly or view it on GitHub.

[nbering]

I want to be able to perform a MySql Dump before the vm is destroyed. The project I'm working on is heavily tied to the database, so I want to persist database changes automatically when the vm is shut down or destroyed. Because vagrant-triggers runs on the host it doesn't have access to the utilities installed on the VM that perform this operation. I could install mysql utilities on the host machine, but that kind of defeats the purpose of using vagrant in the first place.

[kadaan]

Why can't you run the command via WinRM or SSH?

On Nov 9, 2014, at 1:36 PM, Nicholas Bering [email protected] wrote:

I want to be able to perform a MySql Dump before the vm is destroyed. The project I'm working on is heavily tied to the database, so I want to persist database changes automatically when the vm is shut down or destroyed. Because vagrant-triggers runs on the host it doesn't have access to the utilities installed on the VM that perform this operation. I could install mysql utilities on the host machine, but that kind of defeats the purpose of using vagrant in the first place.

—
Reply to this email directly or view it on GitHub.

[gtmtech]

Actually if you want to run a command on the VM, you can use run_remote as opposed to run as specified by https://github.com/emyl/vagrant-triggers/blob/master/lib/vagrant-triggers/dsl.rb in vagrant-triggers.

However I think vagrant-triggers does not allow you to run a parameterised script, like the shell provisioner does. Ultimately the shell provisioner offers more flexibility, it would be nice if there was a mechanism to do the reverse.

Also, with vagrant-triggers, you cannot run further vagrant commands - at one point in the past, I wanted to run vagrant box repackage after a vagrant suspend, but had to delegate this to a controlling wrapper bash script in the end, as vagrant cant call itself, but this isn't likely to ever be functionality it provides I realise that :-)

[dixhuit]

vagrant-triggers also adds a further dependency to projects that rely on this kind of functionality. I'd like to just specify vagrant as a dependency in our project rather than having to list any vagrant plugins as well.

Less dependencies, less complexity, more goodness.

[kadaan]

True, but it seems like the architecture is to start with plugins and move to embedded functionally when it is generic enough. To deal with this, we have created a package with installs vagrant and ensures that the require plugins are installed.

On Nov 10, 2014, at 6:53 AM, Dan Bohea [email protected] wrote:

vagrant-triggers also adds a further dependency to projects that rely on this kind of functionality. I'd like to just specify vagrant as a dependency in our project rather than having to list any vagrant plugins as well.

—
Reply to this email directly or view it on GitHub.

[kadaan]

I believe Vagrant-triggers can ask for user input it that helps.

On Nov 10, 2014, at 6:31 AM, Geoff Meakin [email protected] wrote:

Actually if you want to run a command on the VM, you can use run_remote as opposed to run as specified by https://github.com/emyl/vagrant-triggers/blob/master/lib/vagrant-triggers/dsl.rb in vagrant-triggers.

However I think vagrant-triggers does not allow you to run a parameterised script, like the shell provisioner does. Ultimately the shell provisioner offers more flexibility, it would be nice if there was a mechanism to do the reverse.

Also, with vagrant-triggers, you cannot run further vagrant commands - at one point in the past, I wanted to run vagrant box repackage after a vagrant suspend, but had to delegate this to a controlling wrapper bash script in the end, as vagrant cant call itself, but this isn't likely to ever be functionality it provides I realise that :-)

—
Reply to this email directly or view it on GitHub.

[nbering]

I was not aware that vagrant-triggers would allow you to run commands on the guest machine. I will give this a try for my application. I think everyone would agree that this feature is desirable, that it is silly to duplicate efforts, and that if the feature exists but is not fully baked it should remain a plugin. If or when it is a fully baked feature it would be nice to move it to the set of core features.

[gtmtech]

@kadaan - asking for user input via "ask" et. al. is fine, but generally I shy away from anything that involves user input, as having everything automated is my preferred approach. I can put many 100s of "run" commands in my Vagrantfile in a trigger block, but it is much preferable if I have a lot of work to do on shutdown to call out to a script with parameters, particularly if conditional logic is involved. I'm not knocking vagrant-triggers, it's useful, but if either this, or vagrant itself could on destroying a box call out to a shell script on the host with parameters, that would be the feature that I'm after. I personally dont care where its implemented, but its not implemented anywhere yet. In my view its simpler to either let a plugin handle all shell provisioning and deprovisioning, or let vagrant handle all shell provisioning and deprovisioning - half and half doesnt really make sense to me.

[kadaan]

Fair enough. For what it is worth I need the same so that I can remove machine from LDAP.

On Nov 11, 2014, at 5:50 AM, Geoff Meakin [email protected] wrote:

@kadaan - asking for user input via "ask" et. al. is fine, but generally I shy away from anything that involves user input, as having everything automated is my preferred approach. I can put many 100s of "run" commands in my Vagrantfile in a trigger block, but it is much preferable if I have a lot of work to do on shutdown to call out to a script with parameters, particularly if conditional logic is involved. I'm not knocking vagrant-triggers, it's useful, but if either this, or vagrant itself could on destroying a box call out to a shell script on the host with parameters, that would be the feature that I'm after. I personally dont care where its implemented, but its not implemented anywhere yet. In my view its simpler to either let a plugin handle all shell provisioning and deprovisioning, or let vagrant handle all shell provisioning and deprovisioning - half and half doesnt really make sense to me.

—
Reply to this email directly or view it on GitHub.

[Vincent--]

I use that in order to unregister my box in puppet master and that works quite well 👍

  # To install vagrant-triggers plugin, simply run :
  # "vagrant plugin install vagrant-triggers"
  if Vagrant.has_plugin?("vagrant-triggers")
    # We remove the node from puppet master to avoid certificate issues when we build a new node with same hostname
    # (this is optional but you'll need to do that manually if it isn't done here)
    puppet_node.trigger.after :destroy do
      run "vagrant ssh puppet -c 'sudo puppet node clean " + machine + "'"
      run "vagrant ssh puppet -c 'sudo puppet node deactivate " + machine + "'"
    end
  end

[gtmtech]

I just noticed its almost 2 years since I raised this (via #1302). Do you think it's likely the core team will look at it any time soon? Or would it be better to attempt a PR of my own? Thanks

[komlenic]

I think this should be a core feature due to its utility and varied use-cases, however using the vagrant-triggers plugin is an option.

To implement this functionality using vagrant-triggers plugin, in your vagrantfile you can add:

config.trigger.before :destroy do
  info "Dumping the database before destroying the VM..."
  run_remote  "command"
end

If you prefer to use a shell script to contain all your teardown/cleanup tasks:

config.trigger.before :destroy do
  info "Dumping the database before destroying the VM..."
  run_remote  "bash /vagrant/cleanup.sh"
end

... where /vagrant/cleanup.sh is a script that will exist on both the host and the guest, because vagrant shares the directory containing the vagrantfile on the host, with /vagrant on the guest by default.

[kadaan]

@gtmtech FWIW internally we added support for vagrantfile specified parameters which can be specified in a similar way to triggers. We use it to allow users to pass in their credentials way earlier in vagrant up and to allow them to specify if they want to join the domain. The parameters end up in vagrant up -? just like the native parameters. Would this coupled with vagrant-triggers accomplish what you want?

[gtmtech]

As mentioned back in Nov 11, there's still a bunch of things that vagrant-triggers doesn't address, including the ability with provisioning to run a script rather than just run individual commands (which I believe is still the case with vagrant-triggers - had a quick look and doesn't look like they've added this functionality yet). I know vagrant-triggers is amazingly useful, but I dont think I've ever been convinced that anything will be as neat as the ability to run a parameterised deprovisioning shell script, just like you can run a provisioning one. I'm still a +1 for this.

[gtmtech]

Just did a quick tally, and 45 people have +1'd this feature request, in case that pits it against other requests.

[kadaan]

@gtmtech I believe what I mentioned would allow you to accomplish your goals. You can define required parameters, in the vagrantfile, for any arbitrary command. These parameters are available in the vagrant-triggers definitions. The trigger can run a script on the host or guest.

For example you could define a username parameter for vagrant destroy which would be required when the user runs the command. The value of this parameter is available in the :before-destroy trigger. You can run a script in the trigger using run_remote and pass the param to the script.

Does this accomplish what you want?

[Sander-Toonen]

I just noticed the following message on vagrant destroy:
Running cleanup tasks for 'shell' provisioner...

Does that mean that the functionality is present? If so, could it please be documented?

[thom8]

It's only available if the provisioner supports it -- AFAIK the shell provsioner does not.

[chrisroberts]

Related: #3849

[chrisroberts]

As #3849 encompasses enhancement I'm going to close this one up and keep the other open. Cheers!