community.libvirt icon indicating copy to clipboard operation
community.libvirt copied to clipboard

Split `virt` into specialized modules

Open mlow opened this issue 3 years ago • 0 comments

SUMMARY

Currently virt has rather a lot going on.. it's used both to manage resources (libvirt domains) as well as retrieve information of both individual domains of the libvirt node itself (free memory, etc). I think it would be better to split its functionality into a handful of focused modules. These modules could be added without altering any existing functionality. I would image virt eventually being deprecated.

ISSUE TYPE
  • Refactor
COMPONENT NAME
  • virt
ADDITIONAL INFORMATION

This is motivated by recent work I've been doing with community.libvirt (working towards a clean, declarative way to deploy libvirt VMs, that isn't Terraform, and finding that community.libvirt needs some work done to get me there :).

One of the needs I've encountered is the ability to retrieve a domain's interface addresses (also seen in #124). I've got a working prototype of this, but it's challenging to figure out the best way to supply the flag controlling the source of the addressing info (arp, lease, or agent). Meanwhile I can envision a way of implementing this in a separate module which focuses on information retrieval, with a signature of something like:

---
- community.libvirt.domain_info:
    name: my-domain
    interface_addresses:
      source: agent

Which would return something like:

{
  "changed": false,
  "interface_addresses": {
     ... raw libvirt data
  }
}

This scheme allows for getting multiple bits of information about a domain at once, e.g.:

---
- community.libvirt.domain_info:
    name: my-domain
    state:
    interface_addresses:
      source: agent

... in a GraphQL-esque fashion, returning data in the same "shape" it's been requested in:

{
  "changed": false,
  "state": "running",
  "interface_addresses": {
     ... raw libvirt data
  }
}

The other modules I would expect are:

  • domain - focusing on domain management (idempotent XML definition and state (running, stopped) management)
  • node_info - for retrieval of node-wide information (free mem, etc)

I would love for any feedback on the above proposals. If there's agreement that they seem worthwhile, I'll be happy to get started on them.

Cheers

mlow avatar Oct 03 '22 05:10 mlow