Volume driver azurefile returned an error while trying to query its capabilities, using default capabilties

[kvaes]

FYI - I'm seeing the following error message in my log file (/var/log/syslog) ;

Error Message : Aug 18 11:41:42 oasevmss000002 docker[2607]: time="2016-08-18T11:41:42.087176201Z" level=warning msg="Volume driver azurefile returned an error while trying to query its capabilities, using default capabilties: VolumeDriver.Capabilities: 404 page not found\n"

My scenario ;

• deployed azurefile as docker volume plugin (via command line)
• created three volumes on system (via command line)
• attached volumes to containers (via rancher)

So I'm assuming Rancher is querying the capabilities and that the stub is missing?

[ahmetb]

Yes it looks like Docker changed the API yet again. But is this actually failing things or just a warning?

[kvaes]

That message, as such, isn't failing things (it seems). So no worries...

On a sidenote ; I'm struggling with the -o part, as that's not supported by Rancher. Which results in the following error when oddly enough recreating a container

Aug 18 16:22:02 oasevmss000000 kernel: [37160.120842] aufs au_opts_verify:1597:dockerd[8202]: dirperm1 breaks the protection by the permission bits on the lower branch Aug 18 16:22:02 oasevmss000000 kernel: [37160.216752] aufs au_opts_verify:1597:dockerd[8202]: dirperm1 breaks the protection by the permission bits on the lower branch Aug 18 16:22:02 oasevmss000000 azurefile-dockervolumedriver[33570]: time="2016-08-18T16:22:02Z" level=error msg="could not fetch metadata: cannot read metadata: open /etc/docker/plugins/azurefile/volumes/6880c6d8a57fce46ed1b0a5416c341571119dc757945ff4d899a02c84fe31b0d: no such file or directory" name=6880c6d8a57fce46ed1b0a5416c341571119dc757945ff4d899a02c84fe31b0d operation=get Aug 18 16:22:02 oasevmss000000 azurefile-dockervolumedriver[33570]: time="2016-08-18T16:22:02Z" level=error msg="missing volume option: 'share'" name=6880c6d8a57fce46ed1b0a5416c341571119dc757945ff4d899a02c84fe31b0d operation=create options=map[]

I do love the existence of this plugin, as a way to enable data persistence for Docker containers on Azure. Though I've encountered several limitations ;

• most integrations (like CDN, Copying from VSTS, etc) are blob oriented, and ignore file shares
• file sharing (due to the encryption limitation of SAMBA) cannot go cross-region
• the various "-o" parameters make it hard to integrate with Rancher (and maybe other orchestrators?) So, thinking out loud, maybe an integration focussed on the "typical" blob storage would be more flexible?

[ahmetb]

with the -o part, as that's not supported by Rancher

we've seen this with mesos as well. Nothing we can do about it.

Though I've encountered several limitations ;

Azure File Storage isn't our persistent container volume story. This just fills a gap that exists today, eventually we'll be offering a block-device (data disk) oriented solution.

maybe an integration focussed on the "typical" blob storage would be more flexible?

Nope, been there, done that. https://github.com/ahmetalpbalkan/azurefs You don't want to be in the land of matching file semantics to Azure Blobs. Azure File Storage is designed for file shares, Blob Storage is designed for blobs.

[kvaes]

Insightful! Thanks for the feedback.

Good to hear that there is a persistent volume approach on its way (on the radar anyhow). That would make container designs on Azure stronger.

After reading your response on the blob vs file and semantics mappings. I can understand staying away from it.

[ahmetb]

@kvaes this is now fixed in v0.5.0.