I allready have a docker image to run mopidy on the raspberry pi. I need to run it with --device /dev/snd in order to access the sound card from the container. Is it possible to have this option activated for an hass.io add-on ? If this is possible, I will try to convert it to be run as an add-on.
Since I need to run it on another host, are the add-on runnable independently ?
Edit : I have Mopidy running in a debian based image. I didn’t managed to build a working image with resin/*-alpine.
I will add a device option in 0.28 
You can run every docker image. The base addons are on alpine for size and speed but you can also use a other image.
I will try this at home this evening. Meanwhile, I have a working (beta) version of mopidy on alpine (https://github.com/bestlibre/hassio-addons)
I am planning to host the files on an external usb drive. Could I use a config variable to add a custom volume ? Should I use symbolic links inside the host ? I have the same problem for an influxdb image and for the homeassistant config dir (I prefer to host the files on the usb drive to prevent to many write on the sd card).
I have created a symlink between /usr/share/hassio and the drive, but I’m not sure it is the best method.
Very cool idea to use travis for build docker hub addons 
@bestlibre
Sidenote, I need that also on core repository 
/ you can remove ENV VERSION from your docker scripts, so the new cache feature will work.
If you don’t want use alpine, you can also use a other base Image. Our build scripts work with alpine image with %%BASE_IMAGE%% but if you provide docker hub Image, you can also use every other Image.
I’m open for a feature to move things out but it need to work on generic and resinos too. I will look at this, maby I have a idea. So you need use simlinks at the moment or on generic install, you can change the share folder to usb disk with a install options.
I’m going to test, hopefully tonight, the Alpine based image. If it is working, I’m going to stick to Alpine.
Could it be possible to have, on a per add-on basis, a configurable list /external_dir:/internal_dir (same as devices) ?
You can use /data for persistent storage for your add-on.
But how can I choose the location of this volume on the host ?
The devices option is working great. The mopidy image is outputting audio through the HDMI port of my pi.
I think we need split this question:
ResinOS:
They support only local storage that is limited from resin. It is now possible to mount a USB device into add-on with new devices options. After you add the device into add-on you can mount this volume.
Generic install:
You can use the -d | --data-share option on installer to choice the location of data.
EDIT:
We can make that user can overwrite the devices options to make it more generic and dynamic. But we need first UI support.
At the moment I don’t see a solution for single addon location selection. I think that is not died, but until we have a solution, we can not do that. It is only possible to move the hole data share, work with hardlinks or Mount usb device inside add-on.
The solution need aware of:
I’m thinking about another use case for configurable volumes : data sharing between addons.
I’m planning to do a snapcast server addons. It will either be a standalone addon with mopidy embded, or if there is a possibility to run multiple instance of the same addon with different configuration it will run alongside a dedicated mopidy addon. In the first case it will need access to the same media files than the standalone mopidy addon and in the second one it will need to share the filesink with the mopidy.
Also, the media files could be made accessible via samba, to be used on another host.
The snapcast exemple leads to two other questions :
I have a solution for 0.29 for the external harddisk problem that will work for generic hass.io and don’t affect resinos and make no secure hole. So I will add a mnt to map: [] config that allow you to access to /mnt on your local system.
The second user case with shared data will work with share on map: [] conifg.
This two case will be fix with next version 0.29
For your second problematic:
It is not possible to start 2 instance of same addons, since config and options need to be diferent. The goal of that is to force the problem to the simplistic version that would be possible solve. That help to hold hass.io userfriendly.
For a public add-ons, make 2 addons: a snapcast and mopidy. So the user can use that selective. You can use the new share function of 0.29 and I add this also to standalone samba addon.
Maby you will also write a add-on they sync the share with rsync to a other hass.io host or other. That allow also to use this addon in case above or maby the user have a other usercase to need this and can use that.
I know for sysadmins is that simplify a bit hard, but for the user it make all easy. The best example is the “let’s encrypt” add-on. For user it is so easy to use now ssl certs. First boot it generate the certs and other start of addon renew the certs, he Need not care any things. But for my it was not easy to write the first version 
For private add-ons: you can copy the add-on and make a xy-1 and xy-2 to run two instance. With option image can both add-on use the same Image with diferent configs.
EDIT
I will make a link option that allow your to link our to link add-ons with other if they from same repository. But that will come on 0.30
So I’m going to use a combination of public and private mopidy addons.
What is the docker equivalent of the link option ? If it is --link, it is a deprecated feature (https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/)
About Lets’encrypt, I was thinking to adapt the nginx_proxy (https://github.com/jwilder/nginx-proxy) image to hassio. To use it, each proxified container has to define some environnement variables (-e on the command line, or through the Dockerfile). Can it be done for addons ?
EDIT: Since the nginx_proxy need to be run with “-v /var/run/docker.sock:/tmp/docker.sock:ro”, I will launch it directly on the host since volumes are not available in hassio addons.
Maby my title private/public was a bit wrong. At the end it is your repository and can do what you want do.
Yeah we need that adapt to hass.io and his logic. But hassio have more ability with his option concept as docker with ENVs.
But if I found time I’ll write a hassio addon like this nginx proxy, that is cool.
Edit:
I think to add a option for set env in add-on config is not a bad thing also other docker image. I add that also to 0.29
Could it also be possible to set env for the home assistant container ?
Can we do it. But not with 0.29 and it need UI support or you need set it with curl and hass.io rest api
What is the usercase of that?