You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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 imagevirt
eventually being deprecated.ISSUE TYPE
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 thatcommunity.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:
Which would return something like:
This scheme allows for getting multiple bits of information about a domain at once, e.g.:
... in a GraphQL-esque fashion, returning data in the same "shape" it's been requested in:
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
The text was updated successfully, but these errors were encountered: