Let vagrant know not to track spawned boxes/instances anymore

[Bogdan Sorlea]

This is what I originally posted on the #vagrantup Freenode IRC channel:

BogdanS

heya! a quick question: I am using vagrant with the aws plugin (for aws as provider). If I want to keep the instance around for a long time (or forever), after being spawned with vagrant up --provider=aws, how could I instruct vagrant to just forget about the instance - so that a subsequent vagrant up would create a new one and any vagrant destroy (or anything else) in between would not do anything (pretty much acting like it's not tracking any instance)

is rm -Rf .vagrant (removing the .vagrant folder) enough?

or is there a more elegant approach?

→ favetelinguis has joined

BogdanS

and if rm -Rf .vagrant is the solution, is there something else that needs removing/changing, besides that folder?

Let me know if what I wrote is explicit enough or it requires more explanations. I have a feeling that the answer is not vagrant-aws-specific, that's why I posted it here.

[Alvaro Miranda Aguilera]

hello

from a practical point of view it should work

remove .vagrant on the project folder
then

vagrant global-status
vagrant global-status --prune

should clean

but, from a sysadmin point of view it's scary..

can you look into https://terraform.io/ ?

> --
> 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 vagrant-up+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vagrant-up/7e4069c3-7d6d-432a-8d42-8b2a5a4ac233%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Bogdan Sorlea]

Hey,

I got some answers from the IRC channel as well. The proposed solution there is similar,

rm -Rf .vagrant/machines/<machine name>

vagrant global-status --prune

From the sysadmin perspective, don't worry, it is meant only for easy spawn of testing instances and sandbox instances. The goal is to have production/staging independent of vagrant itself, but still relying on the same cloudinit/puppet configuration. Hope that alleviates some of your concerns. Let me know if I'm crazy, though :)) And thanks for the Terraform tip.

 
 
Cu deosebita consideratie,
Sincerely yours,

Eng. Bogdan Ioan Sorlea

Cell: (+45) 71 99 08 65

Website: http://bogdan.sorlea.com/

Skype: bogdansorlea             Email: bogdan...@gmail.com

"To be trusted is a greater compliment than being loved."
               George MacDonald

"When the power of love overcomes the love of power, the world will know peace."

               Jimi Hendrix         

You received this message because you are subscribed to a topic in the Google Groups "Vagrant" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vagrant-up/VwnTeRGzEmQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vagrant-up+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/CAHqq0ex1VQo4KMEzgMGNcHC%2BH2ztsVLwjRX_R_u89E7ZiZBA6w%40mail.gmail.com.

[Bogdan Sorlea]

PS: wouldn't it make sense to have such a functionality built-in Vagrant itself, rather than to have to hack around?

 
 
Cu deosebita consideratie,
Sincerely yours,

Eng. Bogdan Ioan Sorlea

Cell: (+45) 71 99 08 65

Website: http://bogdan.sorlea.com/

Skype: bogdansorlea             Email: bogdan...@gmail.com

"To be trusted is a greater compliment than being loved."
               George MacDonald

"When the power of love overcomes the love of power, the world will know peace."

               Jimi Hendrix         

[Alvaro Miranda Aguilera]

Hello

Well, if you can share what you require, then someone for sure can
suggest some kind of workflow.

depending on what do you want to do.. vagrant should be the tool for
dev.. but then, you should move to some other workflow

I am totally sold to the hashicorp/atlas idea, so I will suggest check this:
https://hashicorp.com/blog/atlas-mindset.html

Warning, next came from a non-developer:

today a normal workflow goes like this.

You have an app you develop using VMs managed by Vagrant
what's important is the app and not the vm
what can be moved to the base box, you move to the base box, using
packer.io to build a immutable base box
when you are happy with the code, you commit to git
git push trigger a CD/CI that build the app and run tests (This can be
done by jenkins+vagrant, or jenkins+packer)
once the app pass the tests, move some switch from dev to QA, and then
some other workflow approval happen

and when someone approve QA to PROD, will be the new cycle.


Alvaro.

> https://groups.google.com/d/msgid/vagrant-up/CAF3sSE3Wm%2B%3D0y6mzW9evoxHexaa21MDY7_7bO9%3DsSmP0DH6T9Q%40mail.gmail.com.