Hello! Ahh, good point about the "vagrant destroy" also destroying the disks. I hadn't thought about that.
Anyways, what I wanted to do was, well... as I said above - keep the source code and the DB contents outside of the vagrant machine, so that you could update it or recreate it or whatever without it affecting your work. On the other hand, if you DO want to start with a clean slate, you can just manually delete the DB and source folders, and the next "vagrant up" will just bring it all back with defaults. Do you think this is an overkill? Maybe I shouldn't bother with it and just keep the DB inside the box? I suppose a "vagrant destroy" won't be a very often executed command. I use it a lot while putting the machine together and testing out things, but after that... Well, I don't know. I think the machine would get updated now and then so people would need to do a "vagrant destroy"/"vagrant up" to get the latest version... but that's just a guess. Valts. On Monday, September 18, 2017 at 3:18:20 PM UTC+3, Alvaro Miranda Aguilera wrote: > > Hello > > I am not sure I understand the solution very well. > > when Vagrant create a vm, lets say: > > Template -> Guest1 > > and you add a new VDI disk to Guest1 > > it will be exactly the same as putting the mysql db in > /var/something/something > > because if you do vagrant destroy, vagrant will delete the VM and the VM > will cascade the deletion to include the disk that is attached. > > So I am missing something in your persistent story? > > > In the other hand, if you use vagrant triggers, before destroy you could > detach the disk and in this way won't be deleted with a vagrant destroy. > > Now. > > whats the real issue with having developers to delete a local development > db ? > > There are tools that can track schema and data change that can be > incorportated into the code and then other tools can be used to deploy > schema/data changes into a new DB if needed. > > Ie, FLYWAY. > > If you could explain a bit more, I am sure someone here could help better. > > Thanks > Alvaro. > > On Mon, Sep 18, 2017 at 1:54 PM, <[email protected] <javascript:>> wrote: > >> Backstory: I'm making a vagrant box for development. All the software and >> services are running inside the vagrant box (Oracle Virtualbox, Centos 7), >> but two things reside outside: the source code and the MySQL DB. The >> reasoning is that these two things should survive a "vagrant >> destroy"/"vagrant up" cycle. But if the developer wants to start a >> completely clean slate, he should be able to simply delete the appropriate >> folders, and Vagrant will create them anew. >> >> The source code is simply mounted as a shared folder and symlinked where >> it need to be inside the system. That works well. I tried to do the same >> thing with the DB - just pointing MySQL at the shared folder - but the >> world falls apart when the machine is suspended/resumed >> <https://dba.stackexchange.com/questions/185711/running-mysql-in-virtualbox-with-data-dir-on-shared-folder-sometimes-results-in>. >> >> So I'm trying another approach - add a separate virtual disk for MySQL data. >> >> Unfortunately, virtualbox is being a b*tch about it. When you create a >> virtual disk (VDI), it also assigns it a new UUID and then registers both >> the path and the UUID in its internal storage registry. If a developer >> subsequently deletes the file, trying to recreate the file with "vboxmanage >> createhd" will fail because VirtualBox already has a different file >> registered for that path. Simply placing a new file in that location will >> also fail because the UUIDs won't match. To do anything, I need to issue a >> "vboxmanage closemedium" first which removes it from the registry. >> Unfortunately I cannot just execute that command blindly either, because it >> will fail (and in turn trip up vagrant) if the file does not exist in the >> registry. And as far as I'm aware, there's no way I can query the registry >> from within a vagrant script... >> >> One solution would be to use a new random filename each time, but that >> would seriously pollute the Virtualbox storage registry. Also, virtualbox >> likes to complain about invalid disks in its registry. >> >> Any ideas? >> >> -- >> This mailing list is governed under the HashiCorp Community Guidelines - >> https://www.hashicorp.com/community-guidelines.html. Behavior in >> violation of those guidelines may result in your removal from this mailing >> list. >> >> GitHub Issues: https://github.com/mitchellh/vagrant/issues >> IRC: #vagrant on Freenode >> --- >> You received this message because you are subscribed to the Google Groups >> "Vagrant" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/vagrant-up/00ea994e-a6c0-4d65-be3c-2dc0bb3a3ba6%40googlegroups.com >> >> <https://groups.google.com/d/msgid/vagrant-up/00ea994e-a6c0-4d65-be3c-2dc0bb3a3ba6%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Alvaro > > -- This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list. GitHub Issues: https://github.com/mitchellh/vagrant/issues IRC: #vagrant on Freenode --- You received this message because you are subscribed to the Google Groups "Vagrant" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/5e87422b-28cc-4316-a461-dc1342cf0509%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
