Does `vagrant openstack reset` do anything?

[jesusaurus]

After deleting a VM through the openstack api rather than through vagrant, I've reached a state where any vagrant command recommends running vagrant openstack reset including running that recommended command. In #195 it was suggested that the command not use the openstack api but only clean up the .vagrant/ directory, yet I find myself needing to manually delete the machine subdirectory for the VM that was deleted. Additionally, if the entire .vagrant/ directory is deleted while any machine is active then the vagrant openstack provider will lose all information about the running VM and will never be able to connect to it again, forcing users to use the openstack api to delete the VM or accept that it is no longer managed by vagrant. Why doesn't the vagrant openstack reset command address either of these issues?

Why does the openstack provider treat its local state as authoritative instead of as a cache of remote state?

[ggiamarchi]

Actually, this command does not work as it should be. It works only for a single machine Vagrantfile. The current implementation merely delete the folder matching de last machine. This is ok for a single machine configuration but it does not make any sens for a multi-machine one.

I'm not sure to understand what you mean by "the openstack provider treat its local state as authoritative instead of as a cache of remote state". Actually, the only information stored locally regarding OpenStack is the ID of the instance in .vagrant/machines/<<name>>/openstack/id for each Vagrant machine. We can't store less information.

In the case where a machine is deleted, but not deleted by vagrant I think the only thing we can do is to help Vagrant to forget this machine. This was what the reset was supposed to do...

I think we should handle this scenario without relying a command like reset. We could avoid getting an error when running vagrant status like it is now. Instead, we could show machines with a state "deleted" and ensure the command destroy works fine on those machines (destroy would do what reset is supposed to do).

[jesusaurus]

I would expect the reset command to query the openstack API to discover which vagrant VMs are created / not created. But I guess if the only information stored locally is the instance UUID, then losing that local information makes it impossible to know if any VMs running in openstack were created by vagrant.

Maybe we could store a provider UUID in .vagrant/openstack/provider.id and add it to the openstack instances as user-data, that way we could query openstack for running instances and determine if they were created by vagrant, as long as that provider ID hasn't also been deleted.

[ssbarnea]

I find the vagrant openstack reset functionality fully broken because expectations are to do exactly what @jesusaurus describes. What happens is even ironic:

$ vagrant openstack reset                                                                                                                                                                        Vagrant was unable to find the OpenStack instance used for your vagrant machine.
This can happen when the instance has been deleted via OpenStack APIs or OpenStack
Dashboard instead of using vagrant commands.
We recommend using the command `vagrant openstack reset` to reset
vagrant to a clear state
FAIL: 1

I reached a point where all commands give the same error ^:

vagrant up
vagrant destroy
vagrant openstack reset