Skip to content
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

molecule-vagrant does not run box remove on destroy. #290

Open
r-pufky opened this issue Jan 4, 2025 · 2 comments
Open

molecule-vagrant does not run box remove on destroy. #290

r-pufky opened this issue Jan 4, 2025 · 2 comments

Comments

@r-pufky
Copy link

r-pufky commented Jan 4, 2025

To idemptotently destroy a vagrant VM, you must run vagrant box remove box/name otherwise remenants of the VM will remain when re-running molecule create steps, leading hard to debug errors.

Here's the vagrant documentation specifying as such: https://developer.hashicorp.com/vagrant/docs/cli/destroy

On molecule destroy, vagrant should also call vagrant box remove box/name to ensure idempotent testing conditions.

@apatard
Copy link
Member

apatard commented Jan 16, 2025

well, this problem has been there for ages, afair.

From a quick thought:

  • If one wants to make the plugin remove the box, the plugin would have to know it was not already there or something like that,
  • for one task, it's fine but if there are several tests with the same box on the system, downloading each time the box
    would be "annoying" and slowing things a lot.

@r-pufky
Copy link
Author

r-pufky commented Jan 16, 2025

I reported it because it was a violation of the mental model of idempotent test setups for molecule. When using molecule (or any testing framework); I should not need to worry about gotcha's with idempotent testing setups -- they should be setup the same every time -- this lets you focus on actually testing errors within your project opposed to worrying about edge cases in the testing framework.

VM testing is generally a lot heavier to begin with; and I would suggest that most folks already keep their testing to containers for a majority of their testing which does not require stronger abstractions (like, kernel, hardware, firmware, etc). I think sticking to the testing contract of idempotent test setups is more important that it being faster or slower; especially with knowledge that there are other frameworks allowing for lighter testing if needed.

Another way to solve this is to leave it as is, and have an additional option in the configuration which 'enables' the deletion of the box -- so it doesn't break existing users; but allows for people to enable this behavior (maybe like, idempotent: true?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants