go-virtualbox
go-virtualbox copied to clipboard
terra-farm
Investigate which changes to pull in
This repository has quite some forks:
https://github.com/terra-farm/go-virtualbox/network
A number of them contain useful fixes, additions and alike. @VoyTechnology would you be interested to find out which of the changes in these forks would be handy to have in this repo?
Honestly I think it would be better if a library was used which talked to the virtualbox API directly, rather than calling the CLI.
Either this library can be converted to do that, or dropped completely and something else pulled in in this place.
@VoyTechnology with VirtualBox installed, is there a daemon process running with a network API that is also used by VBoxManage? Is there documentation for that API?
It looks like we have to revisit this discussion as mentioned in https://github.com/terra-farm/terraform-provider-virtualbox/issues/54#issuecomment-489355622.
I was looking quite recently at how it can be done, and I agree, not easy to find documentation and and I not particularly knowledgeable about COM APIs myself.
However I did manage to find the SDK PDF: https://download.virtualbox.org/virtualbox/SDKRef.pdf
The WSDL file is contained in the zip file https://www.virtualbox.org/wiki/Downloads#VirtualBox6.0.6SoftwareDeveloperKitSDK
There are several projects which convert from WSDL to go interfaces, like https://github.com/fiorix/wsdl2go and https://github.com/hooklift/gowsdl (first results from Google, I am not sure are they actually good or not).
If I have any spare time I can try and hack something together as Proof of Concept to see is it feasable to convert this project to use the SDK directly.
@VoyTechnology great. Let's evaluate with a proof of concept. I only have one end-user requirement: this project (and the TF provider) should work with VirtualBox without any additional config needed.
As an example of this, I looked at working against VBoxWeb first, but this would then require the user to setup VBoxWeb after installing VirtualBox. Too much complexity and hassle for the user... 😉
I am not sure is pulling in the changes the greatest idea. This repository could use some general overhaul, like I am trying to do in #40, so I think we should focus on improving the API, and then maybe adding more functionality.