Azure / vagrant-azure

Enable Vagrant to manage virtual machines in Microsoft Azure
MIT License
315 stars 112 forks source link

Resource group deleted on destroy #132

Open codestothestars opened 8 years ago

codestothestars commented 8 years ago

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.

christonog commented 8 years ago

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

devigned commented 7 years ago

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.

codestothestars commented 7 years ago

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.

devigned commented 7 years ago

@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.

ayen-tibco commented 7 years ago

+1

devigned commented 7 years ago

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

cecchisandrone commented 7 years ago

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.

devigned commented 7 years ago

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.

shubhamrajvanshi commented 6 years ago

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.

theabro commented 6 years ago

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.

jacderida commented 4 years ago

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.