vagrant-azure icon indicating copy to clipboard operation
vagrant-azure copied to clipboard

Resource group deleted on destroy

Open codestothestars opened this issue 8 years ago • 11 comments

Vagrant Azure 2.0.0.pre1

vagrant destroy deletes the entire resource group. This seems to be by design. However, it discourages us from sharing the resource group that the VM uses with other resources, for fear of losing all resources within the group if destroy is ever accidentally called. This makes it more difficult to use the VM with resources that need to share a resource group with the VM, such as availability sets.

It would be more useful if the plugin kept track of what resources it created for the VM, and then on vagrant destroy, only deleted those resources, and even then only deleted them if there were no other resources using those resources.

codestothestars avatar Aug 14 '16 13:08 codestothestars

Yes, I've experienced this as well. Also, Vagrant should also create the resource group if it is specified but not created. That way, I don't have to create a resource group ahead of running vagrant up

christonog avatar Sep 08 '16 17:09 christonog

I think the right way to do this is to tag the resources uniquely and destroy only those tagged resources we create. It will take a bit to add this, but it shouldn't be too tough.

devigned avatar Feb 02 '17 01:02 devigned

Out of curiosity, would you do that using some caching facility that (I assume) Vagrant has? i.e. vagrant-azure creates the resources and then locally stores their IDs to refer back to later? I don't know much about how Vagrant works and this is something I've wondered about when pondering this issue.

codestothestars avatar Feb 02 '17 15:02 codestothestars

@codestothestars, this module (https://github.com/Azure/vagrant-azure/blob/v2.0/lib/vagrant-azure/util/machine_id_helper.rb) provides the functionality for serializing / de-serializing the persisted machine identifier. Vagrant persists this to disk in the local directory in the .vagrant directory. Specifically, under ./.vagrant/machines/{machine_name}/{provider_name} (90% sure that the format). You should be able to see the structure after spinning up a new machine.

devigned avatar Feb 02 '17 15:02 devigned

+1

ayen-tibco avatar Feb 09 '17 14:02 ayen-tibco

This has surprised more than a few people. We'll change this behavior in the next preview release.

devigned avatar Mar 22 '17 15:03 devigned

What is the status of this? I created a multi-machine Vagrantfile and if I try to remove only one machine the resource group is deleted and second machine is lost.

cecchisandrone avatar Jun 26 '17 12:06 cecchisandrone

I haven't had much time to devote to this project recently. I'll try to give some time to the project in July.

I'm happy to review a PR if anyone is interested in submitting one.

devigned avatar Jun 28 '17 20:06 devigned

Can this be addressed as users might like to launch VM's in specific resource group and keep it even when the VM is deleted.

shubhamrajvanshi avatar May 02 '18 22:05 shubhamrajvanshi

Would it be possible to check on the progress of this please? I would like to be able to specify an already-existing resource group to use, but cannot do this due to the behaviour of vagrant destroy, as it will delete other items in the group I don't want removed.

theabro avatar Oct 03 '18 08:10 theabro

I was just caught out by this today. I wanted to use an existing resource group as it makes the vagrant up much quicker. We had a resource group for running some experimental VMs. Much to my embarrassment, the whole resource group was nuked on my vagrant destroy :(. I deleted some other VMs colleagues had setup.

In my opinion there really should be an option for just removing the machine resources and retaining the group on vagrant destroy.

jacderida avatar Jan 15 '20 12:01 jacderida