-
|
Hi @dmacvicar, I'm using a https://github.com/digitalocean/go-libvirt/tree/main/socket/dialers Is there a specific reason for this? Could (/should?) this plugin be optimised to use the upstream functions instead? Cheers. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
The reason is that the connection URIs where implemented first in our terraform provider. The upstream implementation is not very old, and it is very inspired in ours. Thanks to @zaneb 🎉 The obvious path is to switch to the upstream implementation, but in doing so, we need to see if features would be missing. I am mostly worried about all the ssh features (eg support for local config) and bastion support. We may find a way to just wrap the upstream one and use our implementation for some of the transports. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the details 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Related: #1164 |
Beta Was this translation helpful? Give feedback.
-
|
What Duncan said is correct. FWIW the bug is almost certainly the one described here - the libvirt tls protocol requires you to read a byte from the socket before you do anything else. It appears from that bug report that older versions of go-libvirt somehow masked that issue until mid-2019. |
Beta Was this translation helpful? Give feedback.
The reason is that the connection URIs where implemented first in our terraform provider.
digitalocean/go-libvirt#139
The upstream implementation is not very old, and it is very inspired in ours. Thanks to @zaneb 🎉
The obvious path is to switch to the upstream implementation, but in doing so, we need to see if features would be missing. I am mostly worried about all the ssh features (eg support for local config) and bastion support.
We may find a way to just wrap the upstream one and use our implementation for some of the transports.