New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vagrant destoy deletes everything it has access to #30

Closed
npoggi opened this Issue Aug 7, 2014 · 7 comments

Comments

Projects
None yet
5 participants
@npoggi

npoggi commented Aug 7, 2014

Hi, when doing a vagrant destroy command to delete the VMs created with vagrant up, what actually happends is that the whole cluster is deleted. This includes other VMs not created by the plugin, cloud services, virt net, and any other linked resource.

It should only delete resources created in the vagrant up command.

@jeffmendoza

This comment has been minimized.

Show comment
Hide comment
@jeffmendoza

jeffmendoza Feb 4, 2015

Contributor

need to update the readme for now

Contributor

jeffmendoza commented Feb 4, 2015

need to update the readme for now

@tmaier

This comment has been minimized.

Show comment
Hide comment
@tmaier

tmaier Mar 29, 2015

Sounds scary. A blocker to use it. How serious is this? Will it delete all VMs within a subscription? Or "just" some?

tmaier commented Mar 29, 2015

Sounds scary. A blocker to use it. How serious is this? Will it delete all VMs within a subscription? Or "just" some?

@avishnyakov

This comment has been minimized.

Show comment
Hide comment
@avishnyakov

avishnyakov May 30, 2016

Still open from Aug 7, 2014 for the last two years? :)

avishnyakov commented May 30, 2016

Still open from Aug 7, 2014 for the last two years? :)

@devigned

This comment has been minimized.

Show comment
Hide comment
@devigned

devigned May 31, 2016

Member

In 1.0 this deletes the cloud service specified. If you use the same name as an existing cloud service, it will delete it.

In 2.0, it will delete the resource manager resource group, which will delete all of the items within the resource group. This is intended by design.

Member

devigned commented May 31, 2016

In 1.0 this deletes the cloud service specified. If you use the same name as an existing cloud service, it will delete it.

In 2.0, it will delete the resource manager resource group, which will delete all of the items within the resource group. This is intended by design.

@devigned devigned closed this May 31, 2016

@avishnyakov

This comment has been minimized.

Show comment
Hide comment
@avishnyakov

avishnyakov May 31, 2016

In 2.0, it will delete the resource manager resource group, which will delete all of the items within the resource group. This is intended by design.

Alright, assuming we have "QA" and "STAGING" resource groups building up dozen VMs in each group. Is there a way to build up a "my-vm" in "QA" resource group and then clean up that "my-vm"?

avishnyakov commented May 31, 2016

In 2.0, it will delete the resource manager resource group, which will delete all of the items within the resource group. This is intended by design.

Alright, assuming we have "QA" and "STAGING" resource groups building up dozen VMs in each group. Is there a way to build up a "my-vm" in "QA" resource group and then clean up that "my-vm"?

@devigned

This comment has been minimized.

Show comment
Hide comment
@devigned

devigned May 31, 2016

Member

Yes, but you might or might not like to clean up the associated Virtual Network, the Network Security Group, Network Interface, Public IP and everything else associated. That where it starts to get a little complicated.

The gem could figure out that there is nothing left associated to those resources, but the way I've traditionally used Vagrant, is to spin up self-contained dev environments. That is, the Vagrantfile contains all of the provision a project would required. With that in mind, it has made sense to me that I'd build a resource group, deploy infrastructure to the resource group (only for this project), then tear that down when I'm done with this project.

Thoughts?

Member

devigned commented May 31, 2016

Yes, but you might or might not like to clean up the associated Virtual Network, the Network Security Group, Network Interface, Public IP and everything else associated. That where it starts to get a little complicated.

The gem could figure out that there is nothing left associated to those resources, but the way I've traditionally used Vagrant, is to spin up self-contained dev environments. That is, the Vagrantfile contains all of the provision a project would required. With that in mind, it has made sense to me that I'd build a resource group, deploy infrastructure to the resource group (only for this project), then tear that down when I'm done with this project.

Thoughts?

@avishnyakov

This comment has been minimized.

Show comment
Hide comment
@avishnyakov

avishnyakov May 31, 2016

Resource groups are used exactly as you mentioned - as containers to get a split up per project, per owner, per something else. Also, they are frequently used as const centers.

Having no ability to add/remove/rebuild a VM with in a resource group (say, SharePoint performance testing, scale out, or any other kind of performance / scale-out thing) may limit the usage of the vagrant-azure. Sometimes bozex go crazy, we simple rebuild it from scratch with the same config - a common case, say "win updates" killes the SharePoint, or the VM lost the connectivity or whatever happen so that the while VM goes crazy.

Simple saying, boxes must be disposable. That seems to be a solid statement from the DevOps and infrastructure as a code perspective.

API allows to get all the dependencies for VM, and the make a proper clean up. More a tech challenge to get all correctly, in correct order and the kill it.

avishnyakov commented May 31, 2016

Resource groups are used exactly as you mentioned - as containers to get a split up per project, per owner, per something else. Also, they are frequently used as const centers.

Having no ability to add/remove/rebuild a VM with in a resource group (say, SharePoint performance testing, scale out, or any other kind of performance / scale-out thing) may limit the usage of the vagrant-azure. Sometimes bozex go crazy, we simple rebuild it from scratch with the same config - a common case, say "win updates" killes the SharePoint, or the VM lost the connectivity or whatever happen so that the while VM goes crazy.

Simple saying, boxes must be disposable. That seems to be a solid statement from the DevOps and infrastructure as a code perspective.

API allows to get all the dependencies for VM, and the make a proper clean up. More a tech challenge to get all correctly, in correct order and the kill it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment