Skip to content

Recoverable vms #76

@lg-epitech

Description

@lg-epitech

We have an issue when we create a VM and then we down the database. Those VMs still exist on disk but they we are not keeping track of them whatsoever.

We need to have those endpoints:

  • GET /vms/recoverable - This looks for any vms in /var/lib/distribox/vms that aren't accounted for in the database, this returns it's id, and the image metadata associated (you can get that since we know which image was used).
[
  {
    vm_id: str,
    name: str
    image: str
    version: str
    distribution: str
    family: str
    revision: int
  }
]
  • POST /vms/recover - This takes the new name and resources (cpu, mem and disk usage) for that VM and puts it back in the DB
Body {
  vm_id: str // This is the ID of the VM to recover, make sure this is a recoverable VM, you shouldn't be able to recover a vm that is already tracked
  name: str
  // Here you need to take the specs of the VM, fields are at your discretion but update the schemas on the swagger
}

Response should be the same as creating a VM

  • DELETE /vms/clean/{id} - This takes the ID of the recoverable VM in the body and removes the recoverable vm entirely. Basically like the delete but for recoverable vms
  • DELETE /vms/cleanall - This cleans (deletes) all recoverable vms
  • Update the policies backend/app/core/policies.py and in frontend/app/lib/types/policies.ts
  • Update schemas for swagger

To test this, you can:

# Create VMS

docker compose --profile dev down -v # This downs the database

docker compose --profile dev up --build # Up again

# See that VMS are available in /var/lib/distribox but not in DB anymore

If you have another idea for this, let me know @skl1017

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions