Closed mvance closed 9 years ago
I don't remember it being raised before but it's certainly a good idea and one that would be fairly simple to implement.
In a similar vein, I'm not sure if this warrants a separate ticket or not, but I've noticed that the dump happens prior to the Are you sure you want to destroy the 'vlad' VM?
confirmation step. I'm not sure if the trigger functionality would allow for this, but it would make sense to me if the dump happened after (and only if) the destroy
command has been confirmed.
Hah, yeah I've often wondered the same thing - especially as it overwrites the previous dump file if one exists - but looking at the vagrant-triggers related code I'm really not sure if this is possible ATM.
I've recently been thinking that it may be a good idea to add an option (via settings var) to use timestamps in dump files as a simple way to ensure that they persist - this would at least side step the problem of the previous dump file being overwritten if you'd somehow unintentionally triggered halt/destroy.
Just to follow on from this discussion, it is possible to use a prompt within Ansible to get user input. So we could do something like this:
---
- hosts: all
user: vagrant
gather_facts: false
vars_files:
- "./vars/defaults/vagrant.yml"
- "./vars/defaults/general.yml"
- "./vars/defaults/install.yml"
- "./roles/mysql/defaults/main.yml"
- [ "../../settings/vlad_settings.yml", "../../../settings/vlad_settings.yml", "../settings.yml", "vars/dummy_settings.yml" ]
- [ "../../settings/vlad_local_settings.yml", "../../../settings/vlad_local_settings.yml", "../local_settings.yml", "vars/dummy_settings.yml" ]
vars_prompt:
- name: "vlad_dump_mysql_database"
prompt: "Dump MySQL database?"
default: "n"
tasks:
- debug: var=vlad_dump_mysql_database
I've tested this in the 'vagrant halt' trigger and it works correctly. See the output below (I typed 'y' in this example):
$ vagrant halt
Checking for Vlad settings and local overrides...
Loading Vlad settings file: /Users/philipnorton42/Development/vlad/vlad/settings.yml
==> vlad: Running triggers before halt...
==> vlad: Executing 'halt/destroy' trigger
==> vlad: Executing command "ansible-playbook -i 192.168.100.100, /Users/philipnorton42/Development/vlad/vlad/playbooks/local_halt_destroy.yml --private-key=~/.vagrant.d/insecure_private_key --extra-vars local_ip_address=192.168.100.100"...
Dump MySQL database? [n]:
==> vlad:
==> vlad: PLAY [all] ********************************************************************
==> vlad: 192.168.100.100: not importing file: /Users/philipnorton42/Development/vlad/settings/vlad_local_settings.yml
==> vlad: 192.168.100.100: not importing file: /Users/philipnorton42/Development/settings/vlad_local_settings.yml
==> vlad: 192.168.100.100: not importing file: /Users/philipnorton42/Development/vlad/vlad/local_settings.yml
==> vlad:
==> vlad: TASK: [debug var=vlad_dump_mysql_database] ************************************
==> vlad: ok: [192.168.100.100] => {
==> vlad: "var": {
==> vlad: "vlad_dump_mysql_database": "y"
==> vlad: }
==> vlad: }
==> vlad:
..... snip ....
I'd prefer to see as little prompting on up/down/destroy as possible. I vote we add a variable that can be set to override the default dump on halt/destroy behaviour (keeping the default behaviour as it currently is).
I agree with @danbohea . I'd rather use a local_settings
override for this. I get frustrated enough being prompted for a password for hosts modification, adding another interactive piece wouldn't improve the experience.
Not a problem, I just thought I would float the idea :)
So we just need a local variable, the only thing it needs to do is start with vlad_
.
This is now in the galaxy branch. vlad_db_dump_on_halt_destroy
defaults to true
- setting this to false
will prevent the db dump from being triggered on halt / destroy.
When working with large databases, it would be nice to have the option to not dump the database when destroying a VLAD instance. I thought I might have seen an issue about this previously, but I'm not finding it now.