search

fp7-ofelia / ocf

OFELIA Control Framework (OCF) is a set of software tools for testbed management.
http://fp7-ofelia.github.com/ocf/
Other
18 stars 14 forks source link

Deleting VMs via the tests/deleteVM.py script #140

Closed CarolinaFernandez closed 10 years ago

CarolinaFernandez commented 11 years ago

When an ID is passed to the expedient/src/python/plugins/vt_plugin/test/deleteVM.py file to delete a VM within Expedient, the virtual machine is indeed deleted from Expedient database, but the next time the slice details page is loaded a new VM object is generated...

Maybe because Expedient periodically asks for VMs information to the VT AM, where that object still exists. Then, I believe that a VM must be deleted previously in the VT manager database to avoid this.

Maybe we should change the VT AM way when it comes to removing a VM (if it fails in the normal way proceed to the "script way" [delete VM from server, then itself]; and also delete this VM both in the VT AM db and Expedient db: a full clean in both modules).

This would assume at least the dependency VT AM --> Expedient, of course; but VMs are generated from Expedient nevertheless, so VT AM already depends on Expedient...

Summing up, taking this into account it would be easier for IMs to delete resilient VMs from the VT AM GUI.

Any drawbacks to this or any thought?

msune commented 11 years ago

You are partially right. But the ONLY state which matters is the VM Manager, expedient only has a cache of the RM state (for each slice). The VM Manager MUST be the one to delete the VM state.

The "cache" maintained by Expedient is generated from the list of resources that VM Manager is sending. This cache has an associated hash. For the sake of performance, Expedient plugin is NOT regenerating the whole slice cache from scratch in every query, but relies on the hash. Expedient asks the hash to the VM Manager, if it is the same, then he uses the previously stored cache, if not Expedient regenerates it asking the slice information to the VM Manager.

The problem is likely that when you are deleting the VM, for some reason (aka bug) the VM Manager is sending the same Hash as previously .

Alternatively, VM Manager is not deleting correctly the VM.

Expedient is a GUI, and as such the architecture forbids access to components managed by an AM/RM (like Flowvisor, or Agent). The real state is always the AM/RM.

lbergesio commented 11 years ago

It is the other way around. These scripts are only to clean things after bugs or during development. In principle they are not addressed to be really used in production.

If the vm is broken in both expedient and vt manager, then you need to delete it in vm manager which is the one really keeping the status of the vm. Expedient's gui will be updated next time it is loaded since the vt manager will tell it that vm does not exist.

The script for Expedient is just when something remains there that should not be because the vt manager does not have it.