Open jayhendren opened 6 years ago
The first step is making sure destroy double checks for orphans. Then I can look at perhaps creating another state as Vagrant still creates a VM despite failure - for the most part other drivers like cloud ones destroy the instance if anything bad happens during create. It's less that it refuses to destroy and more it doesn't know it has been created because it receives the error code back from Vagrant.
This might require work in core as well but that's after making destroy
more robust for Vagrant specifically.
It looks like this issue still exists. @cheeseplus are you still working on this or could I perhaps give it a try?
I am not working on it and I've been mostly out of the ecosystem for over a year so go nuts!
It's less that it refuses to destroy and more it doesn't know it has been created because it receives the error code back from Vagrant.
Maybe it's just that I have misplaced expectations, but I would expect an explicit kitchen destroy
to at least attempt a destroy regardless. What it does right now is not make an attempt because of a false assumption about the state of the VM.
It's a reasonable user facing expectation, I was speaking to the problem of an abstraction depending on another abstraction - at some point if you're spending more time trying to catch exceptions of an underlying abstraction then perhaps the model was inherently a poor choice.
The false assumption is due to the nature of how Vagrant fails and because kitchen has a limited window into introspecting information during that initial create window. Aside from catching and parsing the error from Vagrant, an alternative would be some relative path checking alongside vagrant global-status
parsing. This works but only limitedly - kitchen doesn't track the state of it's own config across multiple runs so moves, additions, or removals also fall through in terms of what kitchen knows to cleanup - mentioning this here for some illustration and illumination of how convoluted it can get when trying to do the "most reasonable" thing. Cloud integrations like ec2
are a bit easier to reason with as we're talking to an API and thus ask questions in a common language as opposed to shelling out which is also a notable part of the problem with the existing implementation.
This can be mitigated but at the cost of bolstering each plugin (vagrant in this case) with more discrete updates to it's state tracking. This is doable but as one who has chased a bunch of these types of issues in the ecosystem it requires either a) adding edgecases that are already mirrored in the underlying abstraction ad infinitum in each plugin or b) rethinking how TK manages state holistically.
Elaborating here because these are contributing factors as to why there has been little movement on issues like this - it's solvable (for some value of solvable) but it's diminishing returns and rabbit holes, especially in the case of the kitchen-vagrant abstraction.
Confirmed that this is still occurring. We wil take it into the backlog though we're also interested in community contributions to resolve this, as fixing this in a clean way is a larger undertaking.
Description
If something fails after a VM is created but still during the
kitchen create
step, TestKitchen thinks the VM hasn't been created and will refuse to destroy it.Kitchen Version
ChefDK Version
Platform Version
Arch Linux
Replication Case
Start with no running VMs:
Then during an attempt to create a VM via TestKitchen, the create step fails after the VM comes up:
Consequently, the VM exists according to VirtualBox, but does not exist according to TestKitchen:
And even after a
kitchen destroy
, the VM still exists:I see the same behavior if create fails during
kitchen test --destroy=always
as well.I expect that
kitchen create; kitchen destroy
orkitchen test --destroy=always
will always result in no running VMs leftover, but this behavior does not match that expectation.