Update for a docker driver

[clintkitson]

This commit enables a fully functioning volume driver that is
able to run from VMs in VirtualBox and perform introspection
necessary to issue commands to underlying VB SOAP API
to perform storage orchestration for volume attachemnt.

[md5]

This looks great! I'm glad you were able to build on my work for this. 👍

I haven't had a chance to review this in detail yet, but the first thing that jumps out are the changes to vboxwebsrv/vboxwebsrv.go. Since that file was generated by gowsdl, it may be better to make the changes there and regenerate vboxwebsrv.go.

I'll find some time to review this more fully in the coming week.

[clintkitson]

Btw.. just noticed this is a v4 thing only. The API changed in v5, which I have adjusted for. But I am running into an issue locking the instances while running. I developed the functionality against VirtualBox 4.3.28.

dicey1:siomachine clintonkitson$ VBoxManage storageattach ad92d16a-ef7b-4b4a-abb2-31903dde203f --storagectl "SATA Controller" --port 1 --device 0 --type hdd --medium 4c2a05ee-5a50-4665-9633-2b4530f3cc35
VBoxManage: error: The machine is not mutable (state is Running)
VBoxManage: error: Details: code VBOX_E_INVALID_VM_STATE (0x80bb0002), component SessionMachine, interface IMachine, callee nsISupports

https://www.virtualbox.org/ticket/14936#comment:1

[md5]

I think in general a vboxwebsrv client will probably have to deal with multiple versions of the API. I haven't thought much about how to do that yet, but it would be cool if there were a stable API call to query the version. I haven't yet checked to see if that exists, though querying the WSDL could be an option.

[clintkitson]

I think one of the problems may turn into bloat though. If each SOAP API has its own WSDL with minor changes, then that turns into a ton of extra code as versions change. It might be worth the effort to identify the differences and manually add new methods etc all consolidated under the same vboxwebsrv.go file.

[md5]

I suppose that depends on whether Virtualbox is using semantic versioning for its API or not. I would hope it would be possible to have only V4, V5, etc.

[md5]

It looks like IVirtualBoxgetVersion is the operation to call, but you need to call logon first to get the object to call it on. As long as the logon operation stays consistent, this should be doable, but it seems like it could be brittle. I also took a quick look at the WSDL and it doesn't provide any indication of which version of the API it supports...

[md5]

I've opened hooklift/gowsdl#50 to propose your err handling changes for the generator tool used to generate vboxwebsrv.go.

As for the log.Println changes, I'd rather not bring those in. What would you thing about having the code that uses go-virtualboxclient call log.SetOutput to control where the logging goes instead?

[md5]

Do you recall why you commented this out?

[clintkitson]

Yup agree with your comment above for loglevel. This is necessary due to an error that was being returned. It was throwing a returnval error which seemed aligned to not parsing the information correctly.

[md5]

@clintonskitson FYI, hooklift/gowsdl#50 has been merged. Good catch on the err handling!

[clintkitson]

Verry cool. I have the 5.0.10 WSDL all dialed in and working for the use case. I can re-run it and make the minor tweak re commenting out the XML def as referenced above. Wondering if you would rather have that as the PR for now and then deal with backward/forward versioning in the future? Maybe just leave them as separate branches for now?

[md5]

I'm happy to have this PR just targeting the V4 binding. Opening a branch for V5 compatibility also seems like a reasonable approach until I have the time to work out a better approach. I've created a v5-api branch if you want to send a PR that way.

Regarding the XMLName removal, I'm hesitant to accept a patch that removes it. If you could provide some more information on how it was failing, perhaps including the returned SOAPBody, that would likely help.

[md5]

Actually, perhaps it would be better to have master be V5 and have a v4-api branch...

What do you think?

[clintkitson]

Yeah, I think keeping master at the latest would be the ideal approach.

[md5]

OK. I've killed v5-api and created v4-api.

[md5]

BTW, were there any adjustments needed to the code under virtualboxclient based on the V4 v. V5 api changes?

[clintkitson]

Not for the direct bindings. But there was a helper function for creating
storage that did need to be updated.

On Thursday, December 17, 2015, Mike Dillon notifications@github.com
wrote:

BTW, were there any adjustments needed to the code under virtualboxclient
based on the V4 v. V5 api changes?

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[clintkitson]

Opened #2 and #3