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
I recently implemented a very similar feature in PR #1073 without realizing that #1042 had very recently been merged. I'm happy to close my PR however the output of the node info is incorrect and less expansive than it could.
I believe it to be more expressive and open to upgrading, especially given that the actual topology can be decoded with a bit extra effort.
I am working on two other PR's right now (#1072 and #1059). I'd be happy to rework #1073 to fix the above. My only ask would be to name the parameters as I've done (i.e. cores not cpu_cores_per_socket) mainly because I've used the sames names as libvirt capabilities schema
at the time I implemented node-info using https://libvirt.org/html/libvirt-libvirt-host.html#virNodeInfo which returns what you saw (with incorrect data) and I did not see that virConnectGetCapabilities exists. Since a release was not cut that includes this format, I'd say feel free to update it to the capabilities structure.
Alternatively, you can add a libvirt_node_capabilities data source, which would map to the virConnectGetCapabilities better, if someone is already using the current node_info (doubt it).
Edit: what I needed at the time was a way to determine total memory on the host and cpu cores, in order to make decisions about the number of cpu cores and memory allocated to VMs. On second thought I would recommend implementing an additional data source named libvirt_node_capabilities because memory doesn't "fit" in the capabilities object and to better map 1:1 what libvirt has with what the provider providess
System Information
Linux distribution
any
Terraform version
Provider and libvirt versions
Description of Issue/Question
Setup
I recently implemented a very similar feature in PR #1073 without realizing that #1042 had very recently been merged. I'm happy to close my PR however the output of the node info is incorrect and less expansive than it could.
Example:
produces
By contrast, this is the output of the node info as implemented in PR #1073
The implementation for #1073 libvirt/data_source_libvirt_nodeinfo.go pulls and parses the direct XML dump from virt.
I believe it to be more expressive and open to upgrading, especially given that the actual topology can be decoded with a bit extra effort.
I am working on two other PR's right now (#1072 and #1059). I'd be happy to rework #1073 to fix the above. My only ask would be to name the parameters as I've done (i.e.
cores
notcpu_cores_per_socket
) mainly because I've used the sames names as libvirt capabilities schema@michaelbeaumont @rustydb @dmacvicar
The text was updated successfully, but these errors were encountered: